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

91–100 of 119 posts

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

#91

Post by throwaway2048 »

kentonv wrote: post #62
tmd83 wrote: post #60

Earlier quoted context omitted.

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

Yes, that's what it does. But what's the right policy to set for Apache? Your PHP or whatever code running under Apache could need to do any arbitrary thing. So the pledge would need to be configurable. Probably many PHP developers and sysadmins wouldn't know how to configure it and/or wouldn't care so they'd just turn it off, just like with SE Linux. Moreover, your Apache server running your PHP web app probably leg…

Pledge is not intended for every possible usecase, thats why its part of the program code itself.

If the programmer themseves can make an intelligent decision about if and when to invoke pledge, rather than some predefined policy, you dont have to worry about every single usecase in existence and thus suffer the massively overwrought interfaces this requires. All a programmer has to do in the least effort case is delay pledge calls until after the problematic functionality, or perhaps not use pledge at all.

This is all while obtaining roughly equivilent benfits of something like selinux in a huge majority of cases.

The primary goal of pledge is to make using it as simple as it can possibly be, so it actually gets used.

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

#92

Post by throwaway2048 »

illumen wrote: post #78
friendzis wrote: post #64

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…

Optional things for development are optional so won't always be used. I guess rather than saying "this is a unix program" you could say, this is an OpenBSD program. Which would mean that it has undergone a set of processes for development where all the optional things are not turned off. For example: code review, static analysis, fuzz/quickcheck style testing, using pledge() appropriately, etc. But you'd need to defi…

You dont need executable+writeable memory to run arbitrary code (that would let you reset a mutable pledge)

https://en.wikipedia.org/wiki/Return-oriented_programming

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

#93

Post by throwaway2048 »

friendzis wrote: post #89
mrweasel wrote: post #70

Earlier quoted context omitted.

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…

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…

it would only lead to better security when anyone bothered, which from decades of experience, we know to be essentially never.

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

#94

Post by glass- »

Animats wrote: post #47

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

> Theo is getting good results on tightening up the classic UNIX command line tools. Has he tried EMACS yet?

You may want to take a closer look at the slides about what has been pledged so far. httpd, smtpd, ntpd, relayd, slowcgi, xterm... They're not quite emacs, but they're also not just command line tools.

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

#95

Post by glass- »

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…

> he dismisses SE Linux on that basis. I don't see why the same doesn't apply to pledge.

If you use a Linux distro that enables SE Linux, the second it gets in the way you can turn it off. If you install OpenBSD-current right now, all those utilities use pledge and you can't just turn it off.

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

#97

Post by glass- »

justincormack wrote: post #82
mjn wrote: post #35

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

I don't see how pledge is different from Capsicum which he criticises on this basis, one it is compiled in you cant disable it. (Incidentally Capsicum does seem to be coming to Linux, albeit slowly, and as a self sandboxing technique it is nice to use).

> I don't see how pledge is different from Capsicum which he criticises on this basis, one it is compiled in you cant disable it.

This is addressed in the slides. Capsicum is 5 years old and used in 12 programs because it is difficult to implement. Pledge is 6 months old and used in over 400 programs already.

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

#98

Post by vidarh »

kentonv wrote: post #62
tmd83 wrote: post #60

Earlier quoted context omitted.

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

Yes, that's what it does. But what's the right policy to set for Apache? Your PHP or whatever code running under Apache could need to do any arbitrary thing. So the pledge would need to be configurable. Probably many PHP developers and sysadmins wouldn't know how to configure it and/or wouldn't care so they'd just turn it off, just like with SE Linux. Moreover, your Apache server running your PHP web app probably leg…

For apache:

- Disallow writes to /etc

- Disallow reads of .htpasswd (this would require Apache to rely on a helper to do authentication out-of-process, so not that simple.

- Disallow writes of .htpasswd and .htaccess.

- Disallow writes to all config files evaluated by Apache (if they happens to be outside of /etc)

- Disallow writes to /bin, /sbin/, /usr

- By default disallow network connections to most ports (and yes, you can't prevent connections to the users databases, but preventing an attacker from port-scanning your internal network and trying to connect to other services that may not be sufficiently secured too would be helpful).

- Prevent inbound connections (e.g. lets say someone gets local code execution as the Apache user, and the server isn't sufficiently firewalled; congratulations, you're now running a remote shell that the attacker can use to do more indepth probes for other holes).

- By default disallow writes outside of document roots and a reasonably permissive set of scratch directories (this would probably need a switch to disable, but most won't need it).

Apache could also easily read its config before applying the rules, so adapting the rules to the config files is possible.

(some of the above will hit things like panel applications etc., but the vast majority of users won't run into them and so won't have a reason to disable them; unlike SELinux, the app developers also have the option of not providing a way to blanket disable the security, but instead provide config directives to whitelist directories that fits cleanly into the existing config system).

But for a very specific example of where pledge could have helped and where it'd have been much easier, here's a report of a remote root exploit in exim [1].

This root exploit consisted of using a buffer overflow to overwrite a config file that would then be evaluated, including macro definitions, as root.

If exim had been able to deny the inbound SMTP part to write anywhere but the mail spool this buffer overflow wouldn't have been exploitable (and yes, this case is simple enough that it would have been achievable with chroot() too, so it's more of a generic example of where voluntary restrictions are useful, not just pledge in particular)

[1] http://blog.iweb.com/en/2010/12/security-exploit-identified-...

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

#99

Post by vidarh »

illumen wrote: post #78
friendzis wrote: post #64

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…

Optional things for development are optional so won't always be used. I guess rather than saying "this is a unix program" you could say, this is an OpenBSD program. Which would mean that it has undergone a set of processes for development where all the optional things are not turned off. For example: code review, static analysis, fuzz/quickcheck style testing, using pledge() appropriately, etc. But you'd need to defi…

The "traditional" way of achieving something like this on Unix-like systems is indeed to fork and use the various available mechanisms (different uid's, chroot etc.) to reduce the attack surface but the problem is that it's a lot of work and the classic API's leave you with relatively limited opportunities to relinquish privileges.

Qmail is a good example of this philosophy: Many small binaries that isolate different functionality and are run as different users and mostly communicate via command line and pipes. It makes the attack surface small. But pledge() could have made it even smaller.

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

#100

Post by pferde »

kentonv wrote: post #62
tmd83 wrote: post #60

Earlier quoted context omitted.

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

Yes, that's what it does. But what's the right policy to set for Apache? Your PHP or whatever code running under Apache could need to do any arbitrary thing. So the pledge would need to be configurable. Probably many PHP developers and sysadmins wouldn't know how to configure it and/or wouldn't care so they'd just turn it off, just like with SE Linux. Moreover, your Apache server running your PHP web app probably leg…

You are right, if your webapp requires database connection, the OS has to allow it. That is where application-level security comes in. The OS can not be responsible for everything, the application has to be written securely as well.

This is complementary (and a bit orthogonal) to pledge().

Post reply on HN