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.
But I really don't believe that user optional vs. developer optional makes a difference. The fact is that most app developers do not care to constrain themselves with mitigation layers. Most probably have no idea that this is even a thing they should consider, and of those that do most have other things they'd rather think about. Mitigation layers don't add new features and only fix hypothetical bugs which, sadly, most developers just don't care about.
Building in lowest common denominator checks in the applications that the app developer can know won't get in the way makes it less likely the checks will get disabled.
E.g. your web server could disable filesystem access to paths it doesn't need after having read its config files and determined where it's going to log and where it's going to serve files from, so that things keep working as expected for users, possibly making exceptions for really stupid things (like exposing /etc). That would reduce the chance that users start looking for ways to just turn it off.
That makes the two approaches complementary.
I agree with you that most app developers do not care, but that's besides the point for OpenBSD: They care, and they control most of their own userland.
And you don't really need "most" apps to do it anyway. We'd get far just by having most of the highest profile internet facing server applications support it.
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.
(Incidentally Capsicum does seem to be coming to Linux, albeit slowly, and as a self sandboxing technique it is nice to use).
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.
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.
