OMG! Comic Sans again.
Pledge() – a new mitigation mechanism in OpenBSD
51–60 of 119 posts
Re: Pledge() – a new mitigation mechanism in OpenBSD
#52One 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.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#53Unfortunately 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 :-(
Re: Pledge() – a new mitigation mechanism in OpenBSD
#54Sounds 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…
You are completely missing the entire point, you should figure out what you are missing here.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#55Sounds 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…
> pledge() appears to be voluntary.
As they've used it so far it's not that voluntary for the user. When De Raadt says voluntary mitigations don't work, he's talking about mitigations that a sysadmin can easily disable via settings.
Unless developers build options to control it at runtime then in practice pledge() is a lot less voluntary than SE Linux which has a knob to enable or disable system-wide.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#56Dismissing 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 gratui…
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".
Re: Pledge() – a new mitigation mechanism in OpenBSD
#57Unfortunately 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 :-(
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.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#58Earlier quoted context omitted.
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.
That only works if you've locked down mprotect, mmap, and munmap.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#59Earlier quoted context omitted.
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.
That only works if you've locked down mprotect, mmap, and munmap.
Yes, the parent covered that.
Re: Pledge() – a new mitigation mechanism in OpenBSD
#60Earlier quoted context omitted.
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…
I haven't really read the thing but based off the comment here see if the following makes sense.
Lets say I'm the author of apache http server and I want to make sure that malicious attacks on the http server doesn't escape into remote code execution on the machine and use pledge (or something similar) to sandbox my own code. Taken from another angle when I know that my program deals with untrusted input can I sandbox my program to ensure that if the untrusted input escapes through the security implemented in my program logic is still sandboxed by the OS based off the policy I have set and not the user.