8 ms·

Pledge() – a new mitigation mechanism in OpenBSD

173 points by acchan 11y ago

lobster_johnson 11y ago
Previous discussion: https://news.ycombinator.com/item?id=10306611 https://news.ycombinator.com/item?id=10306611
- LukeShu 11y ago
  That's a very similar presentation, but this one includes some new details. (Notably that it was renamed from "tame" to "pledge")
sarciszewski 11y ago
I would love to see all the other operating systems adopt pledge(), but as is often the case with OpenBSD's security mitigations, it will be years before we see it happen (if at all).
- LukeShu 11y ago
  This is kind-of a different case than most mitigations, though. It's right now only possible because OpenBSD takes a whole-system approach to development; how the different syscall groups work can change, and right now only follows "this seems like it aligns with how we usually do things in OpenBSD." But yes, I would like to see a similar mechanism appear in other operating systems.
  - binarycrusader 11y ago
    OpenBSD is not unique here; Solaris has a "whole-system approach" to development as well, and has had the ability for programs and admins to easily do privilege drop or provide privilege separation for many years now. Not only that, Solaris allows you to wrap programs without any source modifications easily using ppriv to drop or add privileges as required. Almost every slide in the presentation that talks about how you would use the proposed pledge() interface applies to Solaris' privileges model as well. Some relevant examples: http://www.kernelthread.com/publications/security/solaris.html http://www.kernelthread.com/publications/security/solaris.ht... http://docs.oracle.com/cd/E23823_01/html/816-4863/ch3priv-25082.html#eyals http://docs.oracle.com/cd/E23823_01/html/816-4863/ch3priv-25... Solaris' role-based access control and advanced privileges model even lets you implement things like only allowing someone to become 'root' if both them and another person logs in at the same time. Think of the "two-keys required to unlock this door" sort of approach to security: https://blogs.oracle.com/gbrunett/entry/enforcing_a_two_man_rule https://blogs.oracle.com/gbrunett/entry/enforcing_a_two_man_...
    - LukeShu 11y ago
      My point about OpenBSD having a "whole-system approach" was that the interface isn't necessarily general (yet); it just needs to meet the needs of the OpenBSD team as they exist today. When they realize it has a limitation, they can change it, no fuss, because they can commit to the whole system. That said, Solaris' facilities seem useful, but from the documentation you linked, seems much more complicated than pledge(). They look similar conceptually, but Solaris' seems to be much more complicated to actually use.
      - binarycrusader 11y ago
        The examples provided are some of the more complex cases that let you do advanced things. You can shrink the amount of code required if you limit it to more simple cases as those shown in the slides. For example, as derived from the OpenBSD presentation: if (pledge("stdio fattr", NULL) == -1): err(1, "pledge"); A similar (not completely equivalent, since OpenBSD chose some "interesting" definitions for their privileges, and is admittedly untested) example for Solaris might be: priv_set_t *tmp = priv_str_to_set( "PRIV_FILE_READ PRIV_FILE_WRITE PRIV_FILE_CHOWN_SELF", " ", NULL); /* Assert required privileges. */ if (setppriv(PRIV_ON, PRIV_PERMITTED, tmp) == -1) err(1, "setppriv permitted"); if (setppriv(PRIV_ON, PRIV_EFFECTIVE, tmp) == -1) err(1, "setppriv effective"); priv_inverse(tmp); /* Drop all privileges not required. */ (void) setppriv(PRIV_OFF, PRIV_PERMITTED, tmp); The big difference, I think, between the Solaris interfaces and the OpenBSD ones are that Solaris allows the process to temporarily drop privileges and then add them back, or permanently drop them. From the proposed OpenBSD interfaces, it looks they only allow the permanent drop model. There are a few convenience wrappers that might simplify the above further, but the real point is not to compare efficiency of interfaces, but capability. Also, Solaris offers the ability to restrict privileges of programs without source code modification (imagine a program you don't quite trust and don't have the source code to). I didn't see that in the OpenBSD presentation. In their defense, they're also clearly still working on these interfaces, so there can't yet be a fair comparison. Solaris has had privilege interfaces for over a decade, so the model presented is a bit more mature obviously. The only thing I'd mention is that Solaris tries to provide a default set of privileges that represent things closer to administrative boundaries, rather then implementation-specific ones, as implementation can change, but the basic high-level operations do not. For example, Solaris has a file read/write privilege, but doesn't bother letting you restrict the ability to set file timestamps separately because that doesn't seem like a useful thing to do. It does however, provide separate privilege(s) for manipulating ownership of files, since that's clearly a different category of operations. OpenBSD currently seems to be focused on the implementation instead of the administrative-level operations being performed.
- pkaye 11y ago
  Why do you feel this way when even OpenBSD hasn't fully worked out all the details (see the slides) and proven it will work well in practice.
  - sarciszewski 11y ago
    Because I think whitelisting the syscalls at init and only being able to drop syscalls is a great idea.
  - deleted 11y ago
    [deleted]
elchief 11y ago
De Raadt sounds like a pleasant, wise human in his slides (let's not talk about the mailing list). I'm really looking forward to 5.9 if it includes pledge as well as vmm (native hypervisor)
- MBCook 11y ago
  Really? Tame/pledge seems like a good interface but the dig at Linus seemed unnecessary, the masturbating monkey was totally uncalled for, and the coil of poop juvenile. Seriously lowered my view of the presentation.
  - deleted 11y ago
    [deleted]
  - deleted 11y ago
    [deleted]
  - detaro 11y ago
    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".
    - MBCook 11y ago
      Ah. I was not aware of that. I don't blame them for having issues with the way Linux does things (after all they run under different philosophies). But they didn't have to stoop to the same level. It really wouldn't surprise me if something similar ended up in Linux one day. It just seems so clean and simple for the most common cases and small utilities.
    - 1781 11y ago
      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.
badalex 11y ago
For fun I made a perl web app use this. Much simpler than systace or seccomp. I use the path argument as simple form of chroot(2). Previously I had to create a vnd (think loopback device if you are coming from linux) to chroot nicely. On code updates, some process had to rsync static assets into the chroot (I preload all of the needed perl, then chroot()). On linux, the same app uses containers/namespaces. Leveraging read only bind mounts for static assets, seccomp, and various prctrl fiddling. All that ends up being a few hundred lines of code. With pledge is really just a few lines to call the syscall. Much easier to reason about. Even if you end up having to allow most syscalls, the path argument alone IMHO makes it worth it.
andrewchambers 11y ago
Is this a rename of the tame() function that was posted earlier?
- sirsar 11y ago
  Yes. > formerly known as tame() http://www.openbsd.org/papers/hackfest2015-pledge/mgp00002.html http://www.openbsd.org/papers/hackfest2015-pledge/mgp00002.h...
  - andrewchambers 11y ago
    Oh my mistake, I skipped the "About Openbsd" slide because I already knew what openbsd was :).
- cremno 11y ago
  Yes. From the second page: >- formerly known as tame()
- deleted 11y ago
  [deleted]
biot 11y ago
In relation to mitigations, what are the "Loudmouth Linus" and "recent article in Washington Post" references about?
- bronson 11y ago
  http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/ http://www.washingtonpost.com/sf/business/2015/11/05/net-of-... Linus, in one of his less bright moments, called the OpenBSD team a bunch of masturbating monkeys [1]. Unfortunately, the Linux kernel's conspicuous lack of attack mitigation measures (compared to Win/Mac/OpenBSD/etc) does make one wonder who has been masturbating over the past few years. [1] http://article.gmane.org/gmane.linux.kernel/706950 http://article.gmane.org/gmane.linux.kernel/706950 (from the article) (to be clear: I like and use Linux a lot... but Linus's disregard for security is becoming a liability)
- kentonv 11y ago
  http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/ http://www.washingtonpost.com/sf/business/2015/11/05/net-of-... Article could have been good but is a bit too sensationalist, e.g. pointing out that Ashley Madison runs Linux only to admit that it had nothing to do with their security breach -- OK, so why did you mention it, then? (In truth, kernel security rarely matters for servers, because the application is usually the first line of defense. I say this as someone who runs one of the rare services where kernel security does matter, so yeah, I wish Linux did more hardening, but the article is misleading.)
- elchief 11y ago
  Torvalds called openbsd devs "masturbating monkeys" for their focus on security. Wapo had an article on linux security the othe day.
malkia 11y ago
I'm wondering how does this work in a world of plugins? (for example Windows/oSX world, where programs like Autodesk 3DSMax/Maya, Adobe Photoshop, etc. use plugins)? Or applications that embed many utils into one?
- badalex 11y ago
  It's not much different than seccomp/systrace/apparmor/grsec rbac/selinux in that regard. It's per process. So sure, if the plugin forks it could pledge(). Much the same way the plugin could seccomp once forked. Otherwise the plugins rules would be applied to the application. All the same, even if the app used it with most syscalls enabled, it would reduce the attack surface.
  - viraptor 11y ago
    Actually seccomp is per-thread. Small difference, but it does make some lighter use possible in case of plugins.
- Sanddancer 11y ago
  Applications that embed many utils into one almost always have a dispatch tree based on what they were called as and/or what their first argument is. In such an app, the app could figure out what job it's doing at the moment, and then call pledge() appropriately. Pledge() essentially says, "from this point forth, I pledge I will only need syscalls x, y, and z, so don't let me do anything else." For plugins, that gets complicated. That's a case where there would need to be some reworking of how plugins are called, perhaps breaking the program into a series of plugins connected by pipes, where each individual program has its small set of abilities. But that's just an off the top of my head guess, there could very well be a better way of doing it.
- mjn 11y ago
  The simplest case, which is still pretty useful, would be to just have each application require the superset of the syscall functionality any of its components (including any plugins) might require. That would result in fairly broad permissions needed for some apps, but in most cases probably still less than "everything". Plus you get a lot of low-hanging fruit closed off in the rest of the applications, which I think is the main target here: not to harden Photoshop, but to harden the many things in the base system that look more like file(1). There have been actual exploits (multiple ones!) in file(1), where a bug in parsing can result in arbitrary code execution. That's really a failing of the permissions model: file(1) is a program that does nothing but read a file and print a result, so buggy parsing code should have a failure mode no worse than either it crashing, or printing the wrong result. But as-is, since it has the full permissions of the user who ran it, it can do things like email someone your SSH keys, or delete your home directory, which is functionality the binary clearly doesn't need access to for legitimate operation.
nickysielicki 11y ago
Linus is gonna need some ice for that burn on page 3! Jeez!
kentonv 11y ago
Sounds like this could be implemented on Linux as a library on top of seccomp. I'm not impressed by De Raadt's objection to seccomp. BPF programs may technically be turing-complete, but most of the things pledge() does can be implemented by a pretty simple seccomp filter that's just a flat list of conditionals implementing a whitelist or blacklist. Meanwhile De Raadt points out, correctly, that voluntary security mechanisms will be ignored by most developers... but pledge() appears to be voluntary. Seccomp-bpf is often used by sandboxes like Chrome or Sandstorm.io (of which I am lead developer), where it is not voluntary for the code that ends up being run inside the sandbox. But sandbox developers are likely to want seccomp's customizeability over pledge's ease-of-use. So while it's nice that that pledge() is so easy to use, it strikes me that it's targeting the wrong audience with that design.
- tedunangst 11y ago
  How does one whitelist open("/dev/null") with seccomp-bpf?
  - kentonv 11y ago
    I knew someone would ask that. So, the way I'd recommend doing the filename whitelist is by setting up a mount namespace. Create a tmpfs, create the necessary directory tree inside it, bind-mount each whitelisted path in the tmpfs to the real file, then pivot_root into the tmpfs. This sounds complicated but is actually not very much code, and again a library could make it easier. But I think you could also do it with pure seccomp. The trick is to copy the filename list into memory pages that you subsequently mark read-only. Then, have your seccomp filter whitelist specifically pointers to those strings, and prohibit making the pages writable again. (Disclaimer: I just came up with this on a whim, it probably needs more thought.)
    - MBCook 11y ago
      > Create a tmpfs, create the necessary directory tree inside it, bind-mount each whitelisted path in the tmpfs to the real file, then pivot_root into the tmpfs You've made an excellent case for pledge("rpath", ["/dev/null"]);
caf 11y ago
Dismissing SELinux as "optional security is irrelevant" seems pretty silly, since just as one can choose not to use SELinux, they can equally choose not to use OpenBSD. Either way it comes down to the choice of the administrator. OK, people clearly disagree - but I'm still not seeing it, so can someone please explain what's more optional about SELinux than OpenBSD? I mean, I'm not trying to make some kind of a gratuitous dig here, I'm trying to make a serious contribution to the discussion. They're different kinds of mitigation mechanisms anyway, that could easily work together. plege() (and seccomp-bpf) are mitigations intended to be applied by the application author, of the "I know my IRC client should never call ptrace()" sort. SELinux is a mitigation intended to be applied by the system administrator, of the "I know my ETL loader job should only need to read files labelled with loader-input label, write to the directory labelled with the loader-temp label, and connect to the syslog and database sockets" sort.
- throwaway2048 11y ago
  OpenBSD develoers have no control over other operating systems, but they can ensure running OpenBSD means mandatory pledge. It is a given that statements about OpenBSD tech apply only when running openbsd . You are invoking some pretty ridiclous semantics to dispute "optional".
Animats 11y 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.
- JoachimS 11y ago
  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.html http://www.openbsd.org/papers/hackfest2015-pledge/mgp00032.h...
  - ezequiel-garzon 11y ago
    There's mg in base: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/mg.1?query=mg http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...
- friendzis 11y ago
  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.
deleted 11y ago
[deleted]
dantetwc 11y ago
OMG! Comic Sans again.
- illumen 11y ago
  These security hipsters think it makes them cool.
  - TazeTSchnitzel 11y ago
    No, they just enjoy upsetting people who don't like the font :)
- gnuvince 11y ago
  Pretty sure that's not Comic Sans.
- davidgerard 11y ago
  That's not quite Comic Sans. They've actually found a more irritating font, well done OpenBSD! Now, the misspellings "priviledge" and "seperation" ...
X-Istence 11y ago
One 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.
- Ao7bei3s 11y ago
  On the other hand, SELinux protected me against the "venom" VM escape vulnerability earlier this year. That was nice :)
- INTPenis 11y ago
  That is unfortunately a bad practice but there also people out there who leave it in enforcing mode and actually make an effort to use it. I think selinux use has increased lately, at least from my perspective. Where I work I am constantly forcing it on people and volunteer to solve any problems they might have to ease their transition. Just like pledge would require passionate developers who actually care about implementing pledge on the application level, SElinux requires passionate sysadmins who actually care about using it, and about their co-workers using it.
viraptor 11y ago
Unfortunately just the new api is not enough. Developers still need to actually use it. When I researched seccomp and got really excited about it, I submitted a patch to memcached to enable a restrictive policy. The patch/pr is still there, months later. If the project doesn't care, no amazing tool is going to help us :-(
- quanticle 11y ago
  Theo understand that, and that's why he's pushing to get the core OpenBSD userspace tools to use pledge. And hopefully, like many other security innovations, patches will spread from OpenBSD to other operating systems.
JoachimS 11y ago
Not 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 equivalent one etc.). But there are similar ideas. I thought Drawbridge was neat, but seems not to have moved much beyond MSR. http://research.microsoft.com/en-us/projects/drawbridge/ http://research.microsoft.com/en-us/projects/drawbridge/
- pjmlp 11y ago
  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.
- joveian 11y ago
  Interesting... Drawbridge sounds like rump kernels (which can be used in userland processes as well as in VMs), where everything the application does is turned into a small number of hypercalls (12ish IIRC). It seems like there are RISC and CISC forms of higher security system call interfaces (e.g. pledge needing sendsyslog(2) and SOCK_DNS). It is good to see both approaches getting more use :). I hope pledge is adopted widely as it seems like a good approach to easily get significant improvement (particularly when exec is not needed, since restrictions are not inherited). A link to the pledge man page since I haven't seen it mentioned yet: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...
friendzis 11y ago
Well, 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 in rw mode, or silently pipe data to /dev/null on writes. As an added benefit this would teach programmers to actually expect calls to fail and easily test that by applying restrictions. In such environments a program could test its env during initialization and either refuse to start or try to work in a limited fashion. Blowing up during runtime is better than nothing, though still borderline acceptable. Yes, this helps catch misbehaving programs and more importantly highly helps mitigate exploits (exploit automagically runs in isolated jail). Rachel by the Bay has awesome writing [1] on exactly this topic. Makes one think: how many of us have encountered failed fork()/malloc()/fopen()/execve() and are guilty of releasing buggy code, because "f it, highly unlikely, will fix later"? [1]: https://rachelbythebay.com/w/2014/08/19/fork/ https://rachelbythebay.com/w/2014/08/19/fork/
- mrweasel 11y ago
  I think the point that the OpenBSD developers are trying to get across is that if privileges are left for the administrator to deal with, it doesn't get done in most cases. So that leaves the developers to deal with it. Also the developers know if a program needs to write to files or not. Why even leave it as an administrator task to lock down the program, if we already knew that it will never, ever need to write to a file, unless it's being exploited?
  - friendzis 11y ago
    Administrators (FOSS world) can chose where software is installed, what flags it is compiled with, etc., yet vast majority of us just apt-get/yum install and forget - trust the developers (not necessarily upstream) to chose sane defaults for us. The more paranoid use Gentoo/Slackware and fine-tune things themselves. But we are left with that option. Current semantics of pledge() do not leave us this option. There is nothing wrong with shipping default privilege config file along with app, but an option to say "f this shit, vim on my systems does not have access to sockets" without rebuilding from source would actually lead to better security.
deleted 11y ago
[deleted]
dllthomas 11y ago
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 https://lkml.org/lkml/2009/6/24/8 I'd forgotten about it entirely...
fidget 11y ago
Probably worth noting that seccomp bpf programs are pretty far from turing complete. Though they are a bit complex.
Arnt 11y ago
Why is pledge() int rather than void? All the examples exit() in one way or another, so why doesn't pledge() do that for them?
- glass- 11y ago
  The examples are just examples, the uses in the tree are different. For example, ksh doesn't exit if pledge fails, it just prints an error about why it failed and keeps running (imagine how fun it would be the shell did just keep terminating). Other programs use their own logging to report the error, for example httpd logs the error the same way it logs all other fatal errors before it exits.
  - bobdole1951 11y ago
    Heh, that was just changed today: https://marc.info/?l=openbsd-cvs&m=144721043826274&w=2 https://marc.info/?l=openbsd-cvs&m=144721043826274&w=2
ansible 11y ago
SELinux is on by default now with Android. So that's good. I don't know when it will be on by default for the majority of desktop and server users though.
deleted 11y ago
[deleted]
dllthomas 11y ago
I wonder if there is any reason to use pledge() to move between program stages rather than exec(). It would require arranging your executables a little differently, but should be tractable and probably backwards compatible, and the increased resolution would be exposed to existing MAC frameworks.

173 points by acchan 11y ago

lobster_johnson 11y ago

Previous discussion: https://news.ycombinator.com/item?id=10306611 https://news.ycombinator.com/item?id=10306611

LukeShu 11y ago
That's a very similar presentation, but this one includes some new details. (Notably that it was renamed from "tame" to "pledge")

sarciszewski 11y ago

I would love to see all the other operating systems adopt pledge(), but as is often the case with OpenBSD's security mitigations, it will be years before we see it happen (if at all).

LukeShu 11y ago
This is kind-of a different case than most mitigations, though. It's right now only possible because OpenBSD takes a whole-system approach to development; how the different syscall groups work can change, and right now only follows "this seems like it aligns with how we usually do things in OpenBSD." But yes, I would like to see a similar mechanism appear in other operating systems.
- binarycrusader 11y ago
  OpenBSD is not unique here; Solaris has a "whole-system approach" to development as well, and has had the ability for programs and admins to easily do privilege drop or provide privilege separation for many years now. Not only that, Solaris allows you to wrap programs without any source modifications easily using ppriv to drop or add privileges as required. Almost every slide in the presentation that talks about how you would use the proposed pledge() interface applies to Solaris' privileges model as well. Some relevant examples: http://www.kernelthread.com/publications/security/solaris.html http://www.kernelthread.com/publications/security/solaris.ht... http://docs.oracle.com/cd/E23823_01/html/816-4863/ch3priv-25082.html#eyals http://docs.oracle.com/cd/E23823_01/html/816-4863/ch3priv-25... Solaris' role-based access control and advanced privileges model even lets you implement things like only allowing someone to become 'root' if both them and another person logs in at the same time. Think of the "two-keys required to unlock this door" sort of approach to security: https://blogs.oracle.com/gbrunett/entry/enforcing_a_two_man_rule https://blogs.oracle.com/gbrunett/entry/enforcing_a_two_man_...
  - LukeShu 11y ago
    My point about OpenBSD having a "whole-system approach" was that the interface isn't necessarily general (yet); it just needs to meet the needs of the OpenBSD team as they exist today. When they realize it has a limitation, they can change it, no fuss, because they can commit to the whole system. That said, Solaris' facilities seem useful, but from the documentation you linked, seems much more complicated than pledge(). They look similar conceptually, but Solaris' seems to be much more complicated to actually use.
    - binarycrusader 11y ago
      The examples provided are some of the more complex cases that let you do advanced things. You can shrink the amount of code required if you limit it to more simple cases as those shown in the slides. For example, as derived from the OpenBSD presentation: if (pledge("stdio fattr", NULL) == -1): err(1, "pledge"); A similar (not completely equivalent, since OpenBSD chose some "interesting" definitions for their privileges, and is admittedly untested) example for Solaris might be: priv_set_t *tmp = priv_str_to_set( "PRIV_FILE_READ PRIV_FILE_WRITE PRIV_FILE_CHOWN_SELF", " ", NULL); /* Assert required privileges. */ if (setppriv(PRIV_ON, PRIV_PERMITTED, tmp) == -1) err(1, "setppriv permitted"); if (setppriv(PRIV_ON, PRIV_EFFECTIVE, tmp) == -1) err(1, "setppriv effective"); priv_inverse(tmp); /* Drop all privileges not required. */ (void) setppriv(PRIV_OFF, PRIV_PERMITTED, tmp); The big difference, I think, between the Solaris interfaces and the OpenBSD ones are that Solaris allows the process to temporarily drop privileges and then add them back, or permanently drop them. From the proposed OpenBSD interfaces, it looks they only allow the permanent drop model. There are a few convenience wrappers that might simplify the above further, but the real point is not to compare efficiency of interfaces, but capability. Also, Solaris offers the ability to restrict privileges of programs without source code modification (imagine a program you don't quite trust and don't have the source code to). I didn't see that in the OpenBSD presentation. In their defense, they're also clearly still working on these interfaces, so there can't yet be a fair comparison. Solaris has had privilege interfaces for over a decade, so the model presented is a bit more mature obviously. The only thing I'd mention is that Solaris tries to provide a default set of privileges that represent things closer to administrative boundaries, rather then implementation-specific ones, as implementation can change, but the basic high-level operations do not. For example, Solaris has a file read/write privilege, but doesn't bother letting you restrict the ability to set file timestamps separately because that doesn't seem like a useful thing to do. It does however, provide separate privilege(s) for manipulating ownership of files, since that's clearly a different category of operations. OpenBSD currently seems to be focused on the implementation instead of the administrative-level operations being performed.
pkaye 11y ago
Why do you feel this way when even OpenBSD hasn't fully worked out all the details (see the slides) and proven it will work well in practice.
- sarciszewski 11y ago
  Because I think whitelisting the syscalls at init and only being able to drop syscalls is a great idea.
- deleted 11y ago
  [deleted]

elchief 11y ago

De Raadt sounds like a pleasant, wise human in his slides (let's not talk about the mailing list). I'm really looking forward to 5.9 if it includes pledge as well as vmm (native hypervisor)

MBCook 11y ago
Really? Tame/pledge seems like a good interface but the dig at Linus seemed unnecessary, the masturbating monkey was totally uncalled for, and the coil of poop juvenile. Seriously lowered my view of the presentation.
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- detaro 11y ago
  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".
  - MBCook 11y ago
    Ah. I was not aware of that. I don't blame them for having issues with the way Linux does things (after all they run under different philosophies). But they didn't have to stoop to the same level. It really wouldn't surprise me if something similar ended up in Linux one day. It just seems so clean and simple for the most common cases and small utilities.
  - 1781 11y ago
    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.

badalex 11y ago

For fun I made a perl web app use this. Much simpler than systace or seccomp. I use the path argument as simple form of chroot(2). Previously I had to create a vnd (think loopback device if you are coming from linux) to chroot nicely. On code updates, some process had to rsync static assets into the chroot (I preload all of the needed perl, then chroot()). On linux, the same app uses containers/namespaces. Leveraging read only bind mounts for static assets, seccomp, and various prctrl fiddling. All that ends up being a few hundred lines of code. With pledge is really just a few lines to call the syscall. Much easier to reason about. Even if you end up having to allow most syscalls, the path argument alone IMHO makes it worth it.

andrewchambers 11y ago

Is this a rename of the tame() function that was posted earlier?

sirsar 11y ago
Yes. > formerly known as tame() http://www.openbsd.org/papers/hackfest2015-pledge/mgp00002.html http://www.openbsd.org/papers/hackfest2015-pledge/mgp00002.h...
- andrewchambers 11y ago
  Oh my mistake, I skipped the "About Openbsd" slide because I already knew what openbsd was :).
cremno 11y ago
Yes. From the second page: >- formerly known as tame()
deleted 11y ago
[deleted]

biot 11y ago

In relation to mitigations, what are the "Loudmouth Linus" and "recent article in Washington Post" references about?

bronson 11y ago
http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/ http://www.washingtonpost.com/sf/business/2015/11/05/net-of-... Linus, in one of his less bright moments, called the OpenBSD team a bunch of masturbating monkeys [1]. Unfortunately, the Linux kernel's conspicuous lack of attack mitigation measures (compared to Win/Mac/OpenBSD/etc) does make one wonder who has been masturbating over the past few years. [1] http://article.gmane.org/gmane.linux.kernel/706950 http://article.gmane.org/gmane.linux.kernel/706950 (from the article) (to be clear: I like and use Linux a lot... but Linus's disregard for security is becoming a liability)
kentonv 11y ago
http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/ http://www.washingtonpost.com/sf/business/2015/11/05/net-of-... Article could have been good but is a bit too sensationalist, e.g. pointing out that Ashley Madison runs Linux only to admit that it had nothing to do with their security breach -- OK, so why did you mention it, then? (In truth, kernel security rarely matters for servers, because the application is usually the first line of defense. I say this as someone who runs one of the rare services where kernel security does matter, so yeah, I wish Linux did more hardening, but the article is misleading.)
elchief 11y ago
Torvalds called openbsd devs "masturbating monkeys" for their focus on security. Wapo had an article on linux security the othe day.

malkia 11y ago

I'm wondering how does this work in a world of plugins? (for example Windows/oSX world, where programs like Autodesk 3DSMax/Maya, Adobe Photoshop, etc. use plugins)? Or applications that embed many utils into one?

badalex 11y ago
It's not much different than seccomp/systrace/apparmor/grsec rbac/selinux in that regard. It's per process. So sure, if the plugin forks it could pledge(). Much the same way the plugin could seccomp once forked. Otherwise the plugins rules would be applied to the application. All the same, even if the app used it with most syscalls enabled, it would reduce the attack surface.
- viraptor 11y ago
  Actually seccomp is per-thread. Small difference, but it does make some lighter use possible in case of plugins.
Sanddancer 11y ago
Applications that embed many utils into one almost always have a dispatch tree based on what they were called as and/or what their first argument is. In such an app, the app could figure out what job it's doing at the moment, and then call pledge() appropriately. Pledge() essentially says, "from this point forth, I pledge I will only need syscalls x, y, and z, so don't let me do anything else." For plugins, that gets complicated. That's a case where there would need to be some reworking of how plugins are called, perhaps breaking the program into a series of plugins connected by pipes, where each individual program has its small set of abilities. But that's just an off the top of my head guess, there could very well be a better way of doing it.
mjn 11y ago
The simplest case, which is still pretty useful, would be to just have each application require the superset of the syscall functionality any of its components (including any plugins) might require. That would result in fairly broad permissions needed for some apps, but in most cases probably still less than "everything". Plus you get a lot of low-hanging fruit closed off in the rest of the applications, which I think is the main target here: not to harden Photoshop, but to harden the many things in the base system that look more like file(1). There have been actual exploits (multiple ones!) in file(1), where a bug in parsing can result in arbitrary code execution. That's really a failing of the permissions model: file(1) is a program that does nothing but read a file and print a result, so buggy parsing code should have a failure mode no worse than either it crashing, or printing the wrong result. But as-is, since it has the full permissions of the user who ran it, it can do things like email someone your SSH keys, or delete your home directory, which is functionality the binary clearly doesn't need access to for legitimate operation.

nickysielicki 11y ago

Linus is gonna need some ice for that burn on page 3! Jeez!

kentonv 11y ago

Sounds like this could be implemented on Linux as a library on top of seccomp. I'm not impressed by De Raadt's objection to seccomp. BPF programs may technically be turing-complete, but most of the things pledge() does can be implemented by a pretty simple seccomp filter that's just a flat list of conditionals implementing a whitelist or blacklist. Meanwhile De Raadt points out, correctly, that voluntary security mechanisms will be ignored by most developers... but pledge() appears to be voluntary. Seccomp-bpf is often used by sandboxes like Chrome or Sandstorm.io (of which I am lead developer), where it is not voluntary for the code that ends up being run inside the sandbox. But sandbox developers are likely to want seccomp's customizeability over pledge's ease-of-use. So while it's nice that that pledge() is so easy to use, it strikes me that it's targeting the wrong audience with that design.

tedunangst 11y ago
How does one whitelist open("/dev/null") with seccomp-bpf?
- kentonv 11y ago
  I knew someone would ask that. So, the way I'd recommend doing the filename whitelist is by setting up a mount namespace. Create a tmpfs, create the necessary directory tree inside it, bind-mount each whitelisted path in the tmpfs to the real file, then pivot_root into the tmpfs. This sounds complicated but is actually not very much code, and again a library could make it easier. But I think you could also do it with pure seccomp. The trick is to copy the filename list into memory pages that you subsequently mark read-only. Then, have your seccomp filter whitelist specifically pointers to those strings, and prohibit making the pages writable again. (Disclaimer: I just came up with this on a whim, it probably needs more thought.)
  - MBCook 11y ago
    > Create a tmpfs, create the necessary directory tree inside it, bind-mount each whitelisted path in the tmpfs to the real file, then pivot_root into the tmpfs You've made an excellent case for pledge("rpath", ["/dev/null"]);

caf 11y ago

Dismissing SELinux as "optional security is irrelevant" seems pretty silly, since just as one can choose not to use SELinux, they can equally choose not to use OpenBSD. Either way it comes down to the choice of the administrator. OK, people clearly disagree - but I'm still not seeing it, so can someone please explain what's more optional about SELinux than OpenBSD? I mean, I'm not trying to make some kind of a gratuitous dig here, I'm trying to make a serious contribution to the discussion. They're different kinds of mitigation mechanisms anyway, that could easily work together. plege() (and seccomp-bpf) are mitigations intended to be applied by the application author, of the "I know my IRC client should never call ptrace()" sort. SELinux is a mitigation intended to be applied by the system administrator, of the "I know my ETL loader job should only need to read files labelled with loader-input label, write to the directory labelled with the loader-temp label, and connect to the syslog and database sockets" sort.

throwaway2048 11y ago
OpenBSD develoers have no control over other operating systems, but they can ensure running OpenBSD means mandatory pledge. It is a given that statements about OpenBSD tech apply only when running openbsd . You are invoking some pretty ridiclous semantics to dispute "optional".

Animats 11y 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.

JoachimS 11y ago
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.html http://www.openbsd.org/papers/hackfest2015-pledge/mgp00032.h...
- ezequiel-garzon 11y ago
  There's mg in base: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/mg.1?query=mg http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...
friendzis 11y ago
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.

deleted 11y ago

[deleted]

dantetwc 11y ago

OMG! Comic Sans again.

illumen 11y ago
These security hipsters think it makes them cool.
- TazeTSchnitzel 11y ago
  No, they just enjoy upsetting people who don't like the font :)
gnuvince 11y ago
Pretty sure that's not Comic Sans.
davidgerard 11y ago
That's not quite Comic Sans. They've actually found a more irritating font, well done OpenBSD! Now, the misspellings "priviledge" and "seperation" ...

X-Istence 11y ago

One 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.

Ao7bei3s 11y ago
On the other hand, SELinux protected me against the "venom" VM escape vulnerability earlier this year. That was nice :)
INTPenis 11y ago
That is unfortunately a bad practice but there also people out there who leave it in enforcing mode and actually make an effort to use it. I think selinux use has increased lately, at least from my perspective. Where I work I am constantly forcing it on people and volunteer to solve any problems they might have to ease their transition. Just like pledge would require passionate developers who actually care about implementing pledge on the application level, SElinux requires passionate sysadmins who actually care about using it, and about their co-workers using it.

viraptor 11y ago

Unfortunately just the new api is not enough. Developers still need to actually use it. When I researched seccomp and got really excited about it, I submitted a patch to memcached to enable a restrictive policy. The patch/pr is still there, months later. If the project doesn't care, no amazing tool is going to help us :-(

quanticle 11y ago
Theo understand that, and that's why he's pushing to get the core OpenBSD userspace tools to use pledge. And hopefully, like many other security innovations, patches will spread from OpenBSD to other operating systems.

JoachimS 11y ago

Not 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 equivalent one etc.). But there are similar ideas. I thought Drawbridge was neat, but seems not to have moved much beyond MSR. http://research.microsoft.com/en-us/projects/drawbridge/ http://research.microsoft.com/en-us/projects/drawbridge/

pjmlp 11y ago
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.
joveian 11y ago
Interesting... Drawbridge sounds like rump kernels (which can be used in userland processes as well as in VMs), where everything the application does is turned into a small number of hypercalls (12ish IIRC). It seems like there are RISC and CISC forms of higher security system call interfaces (e.g. pledge needing sendsyslog(2) and SOCK_DNS). It is good to see both approaches getting more use :). I hope pledge is adopted widely as it seems like a good approach to easily get significant improvement (particularly when exec is not needed, since restrictions are not inherited). A link to the pledge man page since I haven't seen it mentioned yet: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...

friendzis 11y ago

Well, 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 in rw mode, or silently pipe data to /dev/null on writes. As an added benefit this would teach programmers to actually expect calls to fail and easily test that by applying restrictions. In such environments a program could test its env during initialization and either refuse to start or try to work in a limited fashion. Blowing up during runtime is better than nothing, though still borderline acceptable. Yes, this helps catch misbehaving programs and more importantly highly helps mitigate exploits (exploit automagically runs in isolated jail). Rachel by the Bay has awesome writing [1] on exactly this topic. Makes one think: how many of us have encountered failed fork()/malloc()/fopen()/execve() and are guilty of releasing buggy code, because "f it, highly unlikely, will fix later"? [1]: https://rachelbythebay.com/w/2014/08/19/fork/ https://rachelbythebay.com/w/2014/08/19/fork/

mrweasel 11y ago
I think the point that the OpenBSD developers are trying to get across is that if privileges are left for the administrator to deal with, it doesn't get done in most cases. So that leaves the developers to deal with it. Also the developers know if a program needs to write to files or not. Why even leave it as an administrator task to lock down the program, if we already knew that it will never, ever need to write to a file, unless it's being exploited?
- friendzis 11y ago
  Administrators (FOSS world) can chose where software is installed, what flags it is compiled with, etc., yet vast majority of us just apt-get/yum install and forget - trust the developers (not necessarily upstream) to chose sane defaults for us. The more paranoid use Gentoo/Slackware and fine-tune things themselves. But we are left with that option. Current semantics of pledge() do not leave us this option. There is nothing wrong with shipping default privilege config file along with app, but an option to say "f this shit, vim on my systems does not have access to sockets" without rebuilding from source would actually lead to better security.

deleted 11y ago

[deleted]

dllthomas 11y ago

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 https://lkml.org/lkml/2009/6/24/8 I'd forgotten about it entirely...

fidget 11y ago

Probably worth noting that seccomp bpf programs are pretty far from turing complete. Though they are a bit complex.

Arnt 11y ago

Why is pledge() int rather than void? All the examples exit() in one way or another, so why doesn't pledge() do that for them?

glass- 11y ago
The examples are just examples, the uses in the tree are different. For example, ksh doesn't exit if pledge fails, it just prints an error about why it failed and keeps running (imagine how fun it would be the shell did just keep terminating). Other programs use their own logging to report the error, for example httpd logs the error the same way it logs all other fatal errors before it exits.
- bobdole1951 11y ago
  Heh, that was just changed today: https://marc.info/?l=openbsd-cvs&m=144721043826274&w=2 https://marc.info/?l=openbsd-cvs&m=144721043826274&w=2

ansible 11y ago

SELinux is on by default now with Android. So that's good. I don't know when it will be on by default for the majority of desktop and server users though.

deleted 11y ago

[deleted]

dllthomas 11y ago

I wonder if there is any reason to use pledge() to move between program stages rather than exec(). It would require arranging your executables a little differently, but should be tractable and probably backwards compatible, and the increased resolution would be exposed to existing MAC frameworks.