Reasons to disable / enable SELinux

Question

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.

View more solutions

Comments

[Govindarajulu]

Interesting. What distro are you on? I've never used AppArmor, but I'm curious what distro has it configured out of the box and what the characteristics are. Will look into this. Personally, I do not have trouble with SELinux, btw, but it does take some getting used to.

[Govindarajulu]

I don't think Oracle officially supports SELinux tho

[andrewd18]

AppArmor was originally developed by Novell and is included by default in all of their openSUSE and SUSE Linux Enterprise distributions. It's enabled by default on the Enterprise distros, and is easy to turn on in the consumer distros. Ubuntu has had it since 7.04, but it doesn't automatically enforce every application by default.

[Govindarajulu]

I think I remember some talk about Novell laying off most of the AppArmor team. Wasn't Ubuntu dropping it from the distro? Or am I hearing the voices in my head again? ;-)

[LiraNuna]

Novell did - but the author still works on it unpaid. It's still supported on ubuntu, and stuff like cups and mysqld are being enforced by default.

[rev]

Not always but often we trade ease of use for security and vice versa. It is a balancing act and the answer is not trivial mostly due to defining risks and security goals is a very difficult task.

[kmarsh]

An "enterprise" software vendor hired to install their product handled a permission problem by doing a chmod -R 777 * on a large directory tree. They truly don't care about your security.

[DCookie]

+1, very useful information.

[Ophidian]

+1 for pointing out you're often better served to leave SELinux running and only turn it off to verify whether it is the source of an issue.

[Secoe]

Actually there are cases where SELinux can interfere with applications in Permissive mode. One: at some points of time some rules enforced, despite the system being set to be permissive. Not sure if this is still the case. Two: the time taken to process the rules can be enough to screw up IPC. I've seen this with Oracle clusters. Again in the past and not sure what current status is. But remember nearly every system call has a little processing time added to it.

[Maxim]

AppArmor was integrated into the October 2010, 2.6.36 kernel release.

[Kevin C]

@tylerl why do you say that companies like Oracle don't factor SELinux in their business plan. Do you have an article, or is this more of a personal expierience?