Reasons to disable / enable SELinux

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.

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.

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

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.

I disabled SELinux for AppArmor, I found it much friendlier and easy to maintain than SELinux.

There is no reason to turn it off when you can run it in Permissive mode. It will not interfere with the running application and it will still provide useful security logging. The only exception is about the user contexts: if you are changing between different users living inside another linux instance running in a chroot you could have issues.

SE Linux is not as hopelessly unfriendly as it used to be, at least it's not in commercially supported distros like RHEL5. For the most part you can leave it on, and it'll be fine with anything provided by RedHat. With anything else it can be variable. The problem is that professional service work to get applications working with SE Linux enabled is a nice revenue stream for companies like RedHat and Oracle, so they have no incentive to make everything work nicely ootb.