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

31–40 of 119 posts

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

#31

Post by Sanddancer »

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?

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.

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

#32

Post by MBCook »

detaro wrote: post #28
MBCook wrote: post #18

Earlier quoted context omitted.

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.

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

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.

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

#33

Post by kentonv »

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.

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 aren't likely to use it.

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

#34

Post by MBCook »

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…

> 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"]);

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

#35

Post by mjn »

kentonv wrote: post #33
protomyth wrote: post #30

Earlier quoted context omitted.

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.

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 perspective of the developer, but not the user, so once some piece of software implements it, it gets the protections without users having to set up an optional security policy, or being able to disable the one-and-only-one security policy (short of editing the pledge() calls out of the software and recompiling). And I gather that the OpenBSD developers will be patching software in the ports tree themselves, even if upstream doesn't, so that the OpenBSD version of as much software as possible uses it.

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

#36

Post by kentonv »

MBCook wrote: post #34
kentonv wrote: post #25

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

> 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"]);

I am saying we can and should have a library that offers that interface, yes, but that having the lower-level building blocks available is also important.

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

#37

Post by protomyth »

kentonv wrote: post #33
protomyth wrote: post #30

Earlier quoted context omitted.

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.

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…

That's not the type of optional he means. If I put it in my program, it's not optional when my program runs. As a developer, I cannot depend on SELinux being enabled to protect my code from an exploit. I'm sure some developers won't use it, but that's just another indication of trust.

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

#38

Post by caf »

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.

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

#39

Post by andrewchambers »

kentonv wrote: post #33
protomyth wrote: post #30

Earlier quoted context omitted.

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.

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 think the simplicity is a key factor. Some security everyone can understand is better than good security few can understand.

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

#40

Post by viraptor »

tedunangst wrote: post #23
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…

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.
Post reply on HN