Pledge stops trusted software from being exploited. I trust Apache (I run it as root) but the authors can't guarantee that it can't get exploited, so it's protected by pledge. If I didn't trust Apache, I wouldn't trust that it pledged anything.
SELinux secures un-trusted code. So if I download a program off the internet and run it as nobody, it shouldn't exploit something to get root. This is useful when downloading random closed-source programs (such as on Android).
Unfortunately, Linux relies on SELinux to solve problem #1 (how do I know which files does Apache really need, and which won't help security exploits), which is why it gets such a terrible reputation.
Usually only targeted applications are confined by default and allowing unconfined applications to run without any protection.
Apparmor is easy and anyone can understand how it works after reading the wiki, while apparmor also has neat functions you need to compile them in sadly :(
OpenBSD is great, first you can leave it running for a long time without thinking about security bugs or updates, instead Linux you have to keep close eye to kernel updates & application patches, that's why things like mailservers & DNS & NTP and more are running OpenBSD because I know it doesn't need critical updates every week and uptime is critical for me.
That being said, I think Docker and other container systems are going to remove the need for these security profile systems.
Yes, if there is exploitable code in the container, it can read/write to other things in the container. But so long as you keep the docker daemon up to date on its security patches, application exploits shouldn't be able to leak beyond the container, with the exception of volumes and linked containers/ports.
A kernel exploit executed in a Docker container would compromise all the other Docker containers on the same machine (and the machine as a whole).
SELINUX=disabledThinking about it (maybe because I am watching a update go as I type), what the heck does this say about how we program? I guess in some ways its why I like the idea of pledge. It makes me think better of the programmer because they have put some thought into their program. I'm not sure what I should think when I see SELINUX=disabled as a possible solution.
SELinux is not complex because we program in complex ways, but because we don't know the target program.
For example, (again, nothing against Apache but...) if I want to secure Apache, there's no way for me (as a sysadmin) to tell exactly which files, exactly which syscalls, and exactly which libs does it need to function, and there's no way for me to stay on top of it.
And the same applies to any other complicated software. How to I lock down X? Firefox?
Really, the beauty of a "pledge" like system is that the programmer/PM of the code (which he should understand) should know how to lock it down
https://selinuxproject.org/files/2008_selinux_developer_summ...
I do like pledge, though. I promoted API reduction a long time. Even deleting the code in kernel for appliances a la Poly2 project. Only so much can be gained with it, though.
Quicker, but not cheaper
For example, even assuming privilege escalation isn't a possibility, www-user can read /etc/passwd, getting all usernames. Containers help mitigate this.
The whole idea behind selinux is to prevent this scenario from ever happening. Apache has a policy written for it, that specifies precisely which paths and contexts apache needs <X> type of access to. If it tries to access anything outside those paths and context, the selinux module denies the attempt. It's foolproof if you use it. It's also incredibly annoying if you are on a system with selinux enabled, but aren't familiar with selinux.
seriously ?
Also his counter-argument on secure-levels is not convincing.
"Securelevels are an interesting concepts and they do help with security somewhat. Securelevels can only be increased not decreased on a running system. The higher levels prevent writing to /dev/mem and /dev/kmem, removing file immutable flags, loading kernel modules and changing pf rules. These all help to restrict what an attacker can do, but do absolutely nothing to prevent reading or changing database records, obtaining user info, running malicious programs etc."
Securelevels are what they are, and should be used accordingly. This is just bad judgement of the technology. Please don't assume something does more than what it actually does, this is not a good practice, please read the documentation and/or talk with the community, securelevels are well documented. It is very bad to expect securelevels to protect your database from being changed or your code from being abused and use that as an argument against the OS.
(edited, small typos: added an "it" and changed SO to OS)