Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pledge() – a new mitigation mechanism in OpenBSD

openbsd.org

Post reply on HN
Print view View original

41–50 of 119 posts

Re: Pledge() – a new mitigation mechanism in OpenBSD

#41

Post by mjn »

malkia wrote: post #15

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?

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.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#42

Post by kentonv »

mjn wrote: post #35
kentonv wrote: post #33

Earlier quoted context omitted.

No, I completely understand that that's the point of pledge. But De Raadt's own slide 5 makes a convincing case that "optional security is irrelevant", and he dismisses SE Linux on that basis. I don't see why the same doesn't apply to pledge. Don't get me wrong, I think it's great for this to be available and I would like to see a similar, easy-to-use seccomp wrapper available on Linux. But, sadly, app developers are…

I'm extrapolating a bit here, since it's not that clear from the slides whether this is precisely what he meant, but I interpreted him to be criticizing optional security on the user side, which SELinux is. Since it's a set of user-configurable local system policies, users can, and often do, just use the most permissive policy possible to avoid having to debug SELinux problems. pledge() is optional from the perspecti…

In practice SE Linux policies are typically maintained by distros, which seems similar to OpenBSD adding pledge() to ports. I'll grant that pledge() will likely have an easier time expressing meaningful policies for many apps, though, since it is applied after initialization and with knowledge of command-line parameters, etc. OTOH, the set of policies expressible with pledge() is much more limited.

But I really don't believe that user optional vs. developer optional makes a difference. The fact is that most app developers do not care to constrain themselves with mitigation layers. Most probably have no idea that this is even a thing they should consider, and of those that do most have other things they'd rather think about. Mitigation layers don't add new features and only fix hypothetical bugs which, sadly, most developers just don't care about.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#43

Post by viraptor »

protomyth wrote: post #30
kentonv wrote: post #19

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 mec…

Your missing the point of pledge. It's for the developer to protect their code from the outside world. A malicious developer won't let we this and will try to obfuscate their intent and code. This is for the honest developer to mitigate the risk of a programming blunder to become a major exploit. Yes, its voluntary, but the developer has a self interest in using it.

You pretty much described seccomp. They do the same thing, just with a different interface.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#44

Post by viraptor »

badalex wrote: post #17
malkia wrote: post #15

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?

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.

Actually seccomp is per-thread. Small difference, but it does make some lighter use possible in case of plugins.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#45

Post by kentonv »

viraptor wrote: post #40
tedunangst wrote: post #23

Earlier quoted context omitted.

How does one whitelist open("/dev/null") with seccomp-bpf?

You can open /dev/null at init time and then lock down open(). Sure - it's not always possible, but it's a solution.

That's definitely a way better strategy than what I said -- when your code is well-designed-enough for it to work.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#46

Post by caf »

kentonv wrote: post #25
tedunangst wrote: post #23

Earlier quoted context omitted.

How does one whitelist open("/dev/null") with seccomp-bpf?

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…

You don't even have to copy the filenames around and mess with changing page permissions - simply doing:

  static const char * const dev_null = "/dev/null";
and then whitelisting the pointer dev_null is sufficient, because string literals are stored in the text section which is mapped read-only.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#47

Post by Animats »

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.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#48

Post by sarciszewski »

pkaye wrote: post #20
sarciszewski wrote: post #3

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

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.

Because I think whitelisting the syscalls at init and only being able to drop syscalls is a great idea.

Re: Pledge() – a new mitigation mechanism in OpenBSD

#49

Post by [deleted] »

pkaye wrote: post #20
sarciszewski wrote: post #3

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

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.

[deleted]
Post reply on HN