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.

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

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