Reasons to disable / enable SELinux
In the line of this question on StackOverflow and the completely different crowd we have here, I wonder: what are your reasons to disable SELinux (assuming most people still do)? Would you like to keep it enabled? What anomalies have you experienced by leaving SELinux on? Apart from Oracle, what other vendors give trouble supporting systems with SELinux enabled?
Bonus question: Anyone has managed to get Oracle running on RHEL5 with SELinux in enforcing targeted mode? I mean, strict would be awesome, but I don't that is even remotely possible yet, so let's stay with targeted first ;-)
Solution 1:
RedHat turns SELinux on by default because its safer. Nearly every vendor that uses Redhat-derived products turns SELinux off because they don't want to have to put in the time (and therefore money) to figure out why the thing doesn't work. The Redhat/Fedora people have put in a massive amount of time and effort making SELinux more of a viable option in the Enterprise, but not a lot of other organizations really care about your security. (They care about their security and the security reputation of their product, which is a totally different thing.)
If you can make it work, then go for it. If you can't, then don't expect a lot of assistance from the vendors out there. You can probably get help from the Redhat/Fedora guys, from the selinux mailing lists and #selinux channel on freenode. But from companies like Oracle -- well, SELinux doesn't really factor in to their business plan.
Solution 2:
Typically you're better off running SELinux in Permissive rather than disabling it entirely. You can then check (via audit2why) after a while to see what kinds of violations would have been denied during your regular usage, and build custom policies via audit2allow if those 'violations' are false-positives for your setup.
I have found SELinux behaviour on non-Fedora derived systems to be significantly touchier than what you get with a typical Fedora/RHEL system by default.
If you haven't seen it already, you may find the Fedora SELinux User Guide educational.
Solution 3:
Reasons for:
- Higher level of security through mandatory access control
- You need a reason beyond higher level of security? :-)
Reasons against:
- Difficult to understand
- Difficult to manage
- Difficult to troubleshoot
That said if you're considering SELinux, I recommend the book SELinux by Example.
I worked for a company that had SELinux enabled, in enforcing mode, on every system. The key for us was understanding and using the audit2allow program which can be used to create new context rules.
First, we'd generate a template with audit2allow, and then use a script to build it, like this:
export NAME="my_serviced"
sudo audit2allow -m "${NAME}" -i /var/log/audit/audit.log > ${NAME}.te
sudo setup_semodule ${NAME}
The setup_semodule script:
#!/bin/sh
# Where to store selinux related files
SOURCE=/etc/selinux/local
BUILD=/etc/selinux/local
NAME=$1
/usr/bin/checkmodule -M -m -o ${BUILD}/${NAME}.mod ${SOURCE}/${NAME}.te
/usr/bin/semodule_package -o ${BUILD}/${NAME}.pp -m ${BUILD}/${NAME}.mod
/usr/sbin/semodule -i ${BUILD}/${NAME}.pp
/bin/rm ${BUILD}/${NAME}.mod ${BUILD}/${NAME}.pp
This builds the module from the template (.te file), generates a package, and then loads the module.
We used Puppet for our configuration management system, and we wrote configuration for Puppet to manage all this.
SELinux Puppet Module:
- http://github.com/sansnoc/puppet/tree/master/selinux
Solution 4:
The reason to turn it off is because it can be a pain to debug.
However we don't turn it off now. We nearly always keep it running. I do occasionally turn it off to quickly verify if SElinux is a problem or not.
It' much easier to debug now, especially if you make yourself familir with audit2allow. You don't really need to understand it with audit2allow, but you can some times end up opening thins up wider than you think with audit2allow. Having said that some SELinux is better than none.
I'm by no means an SELinux expert and have only been using it for a couple of years. I still don't really understand the basics, but I know enough to get apps running, btoh those included with the distro and random stuff compiled of the 'net.
The main thing I've had to use are the ls -lZ (show selinux context), audit2allow, chcon, semodule, getenforce, setenforce and booleans. With those tools I've managed to get every app I needed to running under SELinux.
I find one of he big problems with debugging SELinux problems,, is simply remebering to check for SELinux problems when I have other wise inexplicable problems. It usually takes me a little wile to go "h! check SELinux!!".
According to the bind man page SELinux is far safer than running bind in a chroot jail. A lot of other people who have far more clue than I also recommend it so I run it blindly now. And suspect despite the occasional problem it is probably worth doing.
Solution 5:
I disabled SELinux for AppArmor, I found it much friendlier and easy to maintain than SELinux.