I toyed with a similar idea for Linux a while back. Posted about it but got busy and never followed up: https://lkml.org/lkml/2009/6/24/8 I'd forgotten about it entirely...
Pledge() – a new mitigation mechanism in OpenBSD
71–80 of 119 posts
Re: Pledge() – a new mitigation mechanism in OpenBSD
#72One of the first things that sysadmins at my last place of work would do is turn off SELinux on new installs of RHEL. There were too many times that SELinux would cause issues for them because they didn't understand the built-in policies and where to place stuff. As a security conscious person, it is a HUGE pain in the behind and I've spent many hours debugging SELinux and it's policies.
On the other hand, SELinux protected me against the "venom" VM escape vulnerability earlier this year. That was nice :)
Re: Pledge() – a new mitigation mechanism in OpenBSD
#73Re: Pledge() – a new mitigation mechanism in OpenBSD
#74The 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 permissi…
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 all…
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.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#75The 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 permissi…
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.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#76Probably worth noting that seccomp bpf programs are pretty far from turing complete.
Though they are a bit complex.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#77Well, I have always thought that the best way to solve such problems are selective privileges. Android/iOS have privileges, though those are either all or nothing. Desktop basically has root/non-root. I think this problem should be solved not by the developer: I pledge to only read files, but the user/administrator: you are only allowed to read files; and attempts to do that could either fail hard on opening the file…
> Desktop basically has root/non-root.
UNIX in general yes, Mac OS X and Windows not.
The problem as Theo points out, is getting developers to use it.
For example, Windows has fine grained security for all object handles in the system, but as many security exploits show, almost no one makes proper use of them.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#78Well, I have always thought that the best way to solve such problems are selective privileges. Android/iOS have privileges, though those are either all or nothing. Desktop basically has root/non-root. I think this problem should be solved not by the developer: I pledge to only read files, but the user/administrator: you are only allowed to read files; and attempts to do that could either fail hard on opening the file…
Optional things for development are optional so won't always be used. I guess rather than saying "this is a unix program" you could say, this is an OpenBSD program. Which would mean that it has undergone a set of processes for development where all the optional things are not turned off. For example: code review, static analysis, fuzz/quickcheck style testing, using pledge() appropriately, etc. But you'd need to define the set of processes that need to be followed before it could be called an 'OpenBSD program'. Replace 'OpenBSD program' with whatever you want to call this.
Who should set up the permissions? If you trust the developers, you trust them to set up the permissions for you. However, what happens of you don't trust them? You need administrators and users to be able to tweak what the programs are allowed to do.
What is really great about doing it at the developer level is that the administrator do not need to think about that stuff.
For large programs like emacs, or python, it is unfortunate that you can't disable the privs just for a functional call for example. I'd like to see a discussion on why this wouldn't work? I guess there is a good reason - but they don't say.
If you "allow only these privs until Done" where Done would be defined by the program jumping back to a point set by pledge() call. If the process does not allow writing on executable memory this would work (at least for non jit processes).
I wonder if there are ways this can be used by python. Perhaps using a fork this could be done. The program forks to run just the priv bit of code. It can use pledge() and drop all the stuff it doesn't need - do it's business - then die.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#79Earlier quoted context omitted.
Linus was the one calling the OpenBSD developers "m...... monkeys" (apparently that word triggers the HN spamfilter, I vouched your comment), so I think the OpenBSD guys are allowed to be "a bit miffed".
well, this is a good example of the dangers of dropping to the lower level of the opposition; taken out of context, the images in the slides have a counter-productive effect on the presentation. You just always have to hold higher standards, or get dragged into the mud.
This only happens when we're (and I do mean all of us, not only a general IT crowd, but people, society as a whole) are too serious about ourselves, up to the level of butt-tight about it. I can't get insulted by the shiny pile, I cant get insulted by the monkey. In best case I'll think its mildly funny and adds some... shine to the presentation, at worst I'll think its simply a lack of good taste and move on with it.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#80Not to claim that they are remotely the same, but this reminds me of Microsoft Drawbridge. Drawbridge classifies syscalls into groups and the syscalls an application is allowed to use is registered. When the application is executed a runtime gateway verifies that the application only uses the syscalls that was registered. Drawbridge does more things (generates a library that maps the 800+ syscalls to the group equiva…
Some of the research went into Windows containers in Windows 10, where you can run containers directly on top of Hyper-V instances.
Eventually even how the sandboxing works in Windows 8/10 for store applications.