Pledge() – a new mitigation mechanism in OpenBSD

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.ht... 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_...

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.

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.