Hacker News Reader

Comment by 0x0 | Hacker News Reader

On the other hand, what a modern desktop is sorely lacking right now is protecting users and developers from themselves. Whenever I run "npm install" I have to close my eyes and ignore the chills down my spine thinking about how a thousand random npmjs.org account holders just ran their postinstall scripts on my computer with full access to ~/Documents/. The traditional multi-user Unix permission system is no longer appropriate for the modern waterhole malware world. Nobody cares if you break root and hack system binaries, they can always be restored. The gold is in the user's content. We need a system where regular users don't need to worry about defending against software developers who don't carry the user's best interest in mind, and we need a system where even the cowboy I-know-what-I'm-doing developer doesn't point a gun at their foot, while still providing the freedom to tinker and share.

View on HN

scripts on my computer with full access to ~/Documents/ ... Nobody cares if you break root and hack system binaries

This is exactly it. Unix is a multi-user system trying to cope in a single-user world and it's not working. The Unix threat model is students on a university mainframe trying to break into each other's accounts. It's totally unprepared for a world of single-user devices where non-technical people want to run untrusted software.

Maybe what we need is a granular permissions model for all executables, including those in the terminal. Instead of the binary choice between "this code is allowed to rewrite my operating system if it wants to" and "this code can 'only' read and write all of my user files", what if we had to explicitly give binaries access to specific directories? Network access? The desktop environment? Drawing to the screen anywhere outside of their designated windows?

IMO this is the real innovation of iOS: not simply locking everything down, but locking everything down by default and putting the user in control of where to release those valves. Catalina introduced a fairly ham-fisted version of this that doesn't work super well in practice, but I think they've got the right idea.

Improvement ideas for the Catalina model:

- A terminal interface. Right now if you run a program that tries to access Documents you get a pop-up. If you ran it from the terminal, why not get a terminal prompt, a la sudo?

- A central place to manage all of the permissions you've allowed and disallowed (this may already exist and I just don't know about it)

- No special status for folders like "Documents" and "Downloads"; a generalized way of specifying any arbitrary directory (recursive and non-recursive, maybe with patterns). For regular users there can be a simplified UI overlaid on top, while power-users could manage these directly.

- Separate read and write permissions for files and directories

Imagine if you ran all those NPM install scripts and they only had write permissions to their subdirectory of node_modules, only had read permissions to your path, and would dynamically prompt you if they had a reason to request something beyond that

EDIT: What if you could also designate certain programs as trusted "authorities" that can then automatically delegate these permissions to other programs? Running with the example, you could allow NPM to dole out narrow permissions to postinstall scripts as needed, coming back up to prompt you in unusual cases. This would hugely improve the user-experience issue and these "authorities" wouldn't really have any more power than they already do today.

That does exist: we have ACLs, containers (no, not docker, but the filesystem views and isolation in macOS - and to some extent windows), chroot etc. Beyond that there are systems like AppArmor and SELinux on the Linux side of things.

Problems with all of those: it becomes too much overhead and the additional moving parts create additional places for things to break (and they do break - even in a preconfigured distro).

And this is what Apple has always been best at: taking technologies that already can work and making them into a product that does work, without hassle, for most people.

IMO there are two problems.

The first is that no one actually wants to manage that kind of access. Especially not your every day computer user.

The second, related, problem is that if every app is asking you to review 20 permissions, people are going to stop reading the list and blindly accept. Or at least the people who need the guardrails the most will blindly accept.

For all the crazy granular permissions I just don't see a way for it to work other than a source like Apple doing the review, saying that this app is trying to read your documents for no reason and so it's rejected. But now you're back to all apps going through the app store sandbox.

A highly-granular system can be organized under a simplified, streamlined, user-friendly interface. I fully believe that this could be made to work well.

And the end result would be Catalina ;-)

> Imagine if you ran all those NPM install scripts and they only had write permissions to their subdirectory of node_modules, only had read permissions to your path, and would dynamically prompt you if they had a reason to request something beyond that

This sounds entirely possible to do within the existing macOS sandboxing framework.

Yup. My thoughts, exactly.

The iPhone is a success, because developers are not its target audience.

Vagrant gives this for dev environments.

pledge(2) from OpenBSD pretty much solves this problem.

Seems like docker solves all those issues

Docker is not meant to be used for security.

i don't understand your point about random npm account holders running their scripts on your computer?

When you npm install a single package like vue or react, it drags in a dependency tree that sources a thousand random npmjs packages. Each of these packages may specify a postinstall script that executes at install time. Time and time again, some random leftpad-like dependency might lurk five directories deep and spring a surprise script on you, either because the author is malicious, or they handed over (or sold out) to someone else, or perhaps most likely their npmjs account was simply compromised.

gotcha. oof. :/

Reply on news.ycombinator.com