Hacker News Reader

Comment by nulld3v | Hacker News Reader

They are constantly attacked because they prevent users from modifying the system configuration, not just app developers.

View on HN

From the operating system’s perspective, everything is the user. Or everything is an app developer. Depends on perspective. Disambiguating reliably, in a way you’d consider reasonable, is not trivial (and arguably impossible).

I'm not sure I fully understand you. All those OSes try very, very hard to disambiguate between apps and the user itself?

A program touches a system file. Is it due to its own logic, or is it your editor saving a file?

Pretend you’re the operating system for a moment. What does “the user” look like, if not an app doing things?

Phone-style isolation is more like giving each app a separate user account. With that level of isolation and robust permissions, apps can do very little "on your behalf".

How do you do anything on a computer that’s not via an app of some description? Do you make arbitrary exceptions for the likes of zsh and chmod? How does the OS know that chmod was knowingly run by the user, and not by some “sudo wget” exploit?

> How do you do anything on a computer that’s not via an app of some description? Do you make arbitrary exceptions for the likes of zsh and chmod? How does the OS know that chmod was knowingly run by the user, and not by some “sudo wget” exploit?

I'm not sure what the purpose of the question is, because a unixy command line doesn't use phone-style permissions. I didn't say everything works this way.

If I installed photoshop with phone-style permissions, it wouldn't be able to invoke chmod and wouldn't even be able to access my downloads folder.

(Trying to tighten down a command line shell ends up being a tangent, but the short answer is that zsh itself would need to be trusted and hardened, and wget would not be allowed to run chmod. When it comes to downloading a script and then running that script on purpose, you probably just have to accept that doing so bypasses the permission system. Thankfully I very rarely need to do something like that.)

So you installed a text editor and wanted to edit /etc/hosts. Should the OS permit you to save your changes or not?

Now what should happen if the text editor decides to modify /etc/hosts without your knowledge?

> Now what should happen if the text editor decides to modify /etc/hosts without your knowledge?

Pop up a UAC prompt of course. It worked so well for Vista.

The secure answer is that the OS gives you a trusted file picker and it grants access to that specific file to the text editor.

This works better with a GUI, but you can adapt it to a console too.

If a user can do a thing, then an app can ask the user to delegate those permissions to it. And since 99% of users don’t read permission dialogs, the two ideas are completely equivalent. The only way to prevent an app from doing a thing is to make it impossible.

Even if users do read permission dialogues, how many Adobe users out there actually understand what modifying the hosts file means? There can be no informed consent if the person who's meant to consent doesn't have the tools to understand the information.

I think we agree.

You can put pressure on app developers to use standard installation methods that don't give unrestricted access.

Even if users don't read the permission dialogs, you can make one path a lot easier. And you can flag anything too tricky as malware behavior.

OSes are doing a bad job of this, but they could do much better. Linux is making the most progress on various package formats.

Reply on news.ycombinator.com