Hacker News new | ask | show | jobs
by Animats 3879 days ago
The problem with granular privileges is that programs want too many of them. See any Android flashlight app. Theo is getting good results on tightening up the classic UNIX command line tools. Has he tried EMACS yet?

Also, a bigger problem than system calls is what parts of the file system the program can access. The concept that a program has all the privileges of its owner is the biggest single problem with permissions.

What might work is having a few general classes of programs, with appropriate restrictions. Consider, for example, permission set "game, single player":

- Can read anything in its install package. - Can read/write only to working directory associated with product/user combination. - Can go full screen, use audio output (not microphone), access mouse/touch, etc.

That seems reasonable. Angry Birds could run under those restrictions. For some games, the DRM won't work, the anti-cheating won't work, the ads won't work, the in-game purchasing won't work, the updater won't work, and the social leader board won't work. Still, it would be reasonable to require in an app store that games still work locked down to that level, even if some features are disabled.

One way an app store might make this work is that programs which require very limited permissions are easy to get into the store. Programs which require extensive permissions go into the "adults only" section of the store, or have to go through a source code audit at the developer's expense.

6 comments

Hence why I am a supporter that Apple and Microsoft keep pushing their sandboxing approaches, even with developers screaming along the way.

Eventually we will get it right, because Theo is right, normal people will just disable security, because it is an hassle on their eyes.

One just needs to search the online forums for people asking how to run as root on Mac OS X or Windows.

Exactly why I hate the argument that goes along the lines of "if people disable it, they must not want security!" - or if people buy cheap phones, they must not want it either - and so on.

The people are not at fault, and they don't know about these things. When the security is bad, it's a design problem - therefore, it's the system/platform/app developer's fault (although app developers are much less at fault than the platform developers, since they can also only control what's given to them by the platform vendor).

I think there's a slide to that effect in this presentation: that the development process involves upgrading the apps to the point at which the security can be made mandatory.
One of the most irritating things about Theo is that he keeps being right.
> Theo is getting good results on tightening up the classic UNIX command line tools. Has he tried EMACS yet?

You may want to take a closer look at the slides about what has been pledged so far. httpd, smtpd, ntpd, relayd, slowcgi, xterm... They're not quite emacs, but they're also not just command line tools.

That's probably OpenBSD httpd, not Apache httpd - a vastly simpler creature.
"game, single player"

I don't think this is a permission set so much as it should be a security domain. At the moment we have the (user,group) tuple. The lesson of mobile OSs is that this needs to be (application,user,group) or possibly (vendor,user,group) - because the vendor/application developer is a potentially hostile actor.

Each app having its own "home" directory eliminates so many problems. It gives you a new problem, which is that apps are no longer composable. The solution to that is probably to put the work of choosing which applications are allowed to open which files back into the Finder/Explorer part of the system (which would be able to see everywhere) and let it do the opening.

The problem on android is that you'll have to agree to the list of privileges again in case of an update, so developers usually just grab all the privileges they might need in the future.

Also on Android the thread model is malicious Apps, while on OpenBSD it's trustable executables getting bugs exploited. Malicious Apps can trick with the privileges, exploits have to fight with the privileges that are already set.

Do OpenBSD roll their own version of Emacs? Just securing the base OS with pledge() would be a great achievment imho. And they have covered quite a few applications so far. This includes hairballs like openssl and things like radiusd, sshd. I'm impressed.

http://www.openbsd.org/papers/hackfest2015-pledge/mgp00032.h...

You are right in that programs may (or more likely do) want too many privileges. This is not the problem with granular privileges, but a problem with enforcement. Mobile OSes implement granular privileges as a notification, not enforcement. The privileges should be outside of app control (though notification mechanism would still be convenient to loosen restrictions per app) and enforced.

I see problem that if we allow application to query its capabilites and bail out if flashlight cannot use microphone it kind of defeats the purpose of privileges. The way to go is to silently fail calls and have an API allowing to deal with that easily. The same microphone example - flashlight app could simply get silence from mic stream (makes harder to debug failing legit uses) or simply fail on attempts to open mic stream.

Somebody has a patch for Android which does that. You can deny a program access to your address book, The program still thinks it can access the address book, but sees an empty one.