1) Configure some software you need.
2) The software doesn't work.
3) Disable SELinux.
4) The software works.
5) F--- SELinux.
After a dozen occurrences of this pattern, your experience will have taught you to begin all deployments from step 5 ;)
On the server I usually use Ubuntu and run custom server software running in a container and never have problems.
I really don't see any reason to disable SELinux. Maybe back in RHEL5 days, but not since then. Just educate yourself on some tools. It really isn't that hard.
You may not see a reason to disable SELinux, but not all Linux systems are RHEL, and don't have it enabled to begin with. I personally would not enable it on a system that did not design for it as a default.
setsebool httpd_can_network_connect=1
tail /var/log/audit.log | audit2allowBut it kinds of demonstrate my problem with SELinux: when I had my unix socket issue I tried to debug my problem using my usual tools: strace, ls, ps, dmesg, etc... but I couldn't figure out what wasn't working right. All the permissions looked fine and yet I kept getting cryptic failures.
With something like a jail, once it's set up I can just use my un*x admin experience without having to learn a brand new OS-specific (if not distribution-specific) set of tools.
That's just not true. There is plenty of security technology that doesn't require you to figure out new tools. There is security technology that doesn't have tools at all and there is nothing to figure out. The program either works correctly or it's buggy and there is no knob to make a buggy program correct.
And then there is security technology that is more or less understandable with knowledge of existing Unix tools. pledge() on OpenBSD, for instance, doesn't introduce new fancy tools. A program doing something it promised not to do will get killed with abort trap (which can, admittedly, be a little cryptic if you don't know pledge does that). In addition, the name of the binary, the pid, and the offending syscall is printed in dmesg. Perhaps it would be better still if the dmesg line included the word "pledge" as a hint & guarantee that you'd get relevant results on Google.
My point is that any ACL framework will require configuration, be it SELinux, AppArmor, Tomoyo, or pledge.
If you want to use pledge to confine applications that don't use the pledge API, it will get complicated, too (admittedly not quite as complicated as SELinux, but still).
SELinux writes denials to the audit log and you get plenty of relevant results.
pledge is obviously much more sane than SELinux, but someone has to write a policy no matter what technology is used.
YUP, this right here. SELinux needs to be way more user friendly if you want to see wider adoption.
I wouldn't run an 'exposed' system that had SELinux support (and decent rules) without SELinux. Not discounting chroot, but given root a lot is possible in a jail.
Lxc is much closer to jails in that sense - but eg lxc/Lxd on Ubuntu is hardly (meant to be) a silver bullet.
To make matters worse SELinux-related errors can be pretty arcane if you don't know what's going on. I'm usually a FreeBSD guy but I had to setup a CentOS 7 box a little while ago. I thought I was going insane when I couldn't get nginx to connect to a unix domain socket. After a hour of hair pulling and non-conclusive googling I finally understood that it was SELinux related.
I will admit that after that I simply disabled SELinux and never looked back. The benefits didn't seem worth the hassle to me.
If I want additional security and sandboxing I'd sooner use something like FreeBSD/solaris jails. It's not exactly the same thing of course but I find the mental model a lot simpler ("a machine within a machine") than SELinux's complicated and (IMO) hard-to-debug rules.