SELinux sux

At least, when you forget it’s there. The way Fedora delivers SELinux is a total pain in the derrier. Killer and I are trying to finish off a netboot install for OS upgrades, and all kinds of stuff breaks in weird ways. MySQL, for instance, won’t start up with our stock my.cnf. So I try manually starting mysqld_safe: it works fine. /var/log/mysqld.log complains that there appears to be another instance of mysqld running and it can’t access /tmp/mysql.socket: permission denied.

“service mysqld start” fails, but recreating the environment in- and the arguments with- which it invokes mysqld_safe works fine. I repeat, line by line, the steps that “service mysqld start” goes thru eventually winding up with /tmp/wtf which is actually just “cat /usr/sbin/service >/tmp/wtf”, and it all works. It only stops working when it invoked as /usr/sbin/service.

And before that we had a bigger problem – we installed a bunch of files into /etc/ from a tar file, with tar xzmspS –same-owner -f <filename> and then copied them into /etc/ with cp -a, which the man page says is equivalent to cp -dpPR.

Except once we do that, you can no-longer log into the box. /var/log/secure shows that there is a problem with limits.conf, “permission denied”. The permissions looked fine, I figured maybe the content was garbled. Opening it up in vim I noticed “[dos]” in the status line. Aha! And sure enough, dos2unix /etc/security/limits.conf fixed the problem. But then on the next install test run, it came back, and dos2unix fixed it.

On the third run, I checked the file before copying it. It had unix end-of-lines. Copy the file, logins stop working. Backup the file and then dos2unix it. Diff the two versions of the file – no changes; MD5 checksum the two files – no changes; write a mini-app which does a strict byte-by-byte binary comparison of the file content. No difference.

Finally Ramp wandered by and when I mentioned that it seemed like some “hidden attribute” he remembered SELinux. “Yeah, but we disable that in the kickstart”. So we go look at /etc/selinux/config and, despite the kickstart entry that says selinux –permissive the config file sets it to ENFORCING. GAH!

Enforcing means it’s applying the templates strictly, which specify a whole bunch of tight contexts in which specific applications can run, files and resources they can read/write.

It’s actually really great for a server system, where you know exactly what your app needs to be able to access, if someone manages to find a buffer overrun or some other crazy exploit, it can’t go futzing with stuff you didn’t intend for it to.

And arguably it’s great for a “dumb workstation” setup where you’re likey to go installing crazy stuff that might otherwise offer a hacker the key to your corporate vaults thru sheer ignorance. But you have to actually know that “permission denied” takes on a whole new scope and that it’s enabled even though you said for it not to be.

In short – it boiled down to the fact our config wanted the MySQL socket file to be in “/tmp” but SELinux says that the MySQL server service can only access a socket file called “/var/lib/mysql/mysql.sock” – a change from the default used elsewhere and in previous versions of Fedora. Bleah.

It also adds a fairly heavy performance penalty to any systems under it. It slows fat, bloated Gnome by upto 60%. And it definitely puts the hurt on MySQL.

This last leaves me with a quandry – the security vs performance tradeoff is huge, absolutely something you don’t want a database paying, the point of the local MySQL server is as a performance assist. The game servers do very little direct disk IO after startup – after startup, nothing but logging.

It’s not a great time for me to go learn about SELinux configuration, so I wimped out and went with the default socket location, allowing me to leave SELinux enabled for now, and added an option to our configuration script to offer you a choice of SELinux on or off.

SELinux doesn’t suck, in the right context and … if the light is on.


SELinux has also bit me in the ass several times. I hate to say it, but I end up disabling it to avoid 4 AM callouts. I would rather make all the security decisions myself, than get broadsided by what somebody else has decreed is the Way It Shall Be Done, and my system suddenly picked up via a yum update.

Disable yum while your at it. Only use it when making specific updates.

What I’ve found when I made the jump from core 6 to 8 and encountered SELinux for the first time. Was not to run some of those services. I compiled, installed, and ran under the user intended to control the process. You can then later set it up to start up on boot.

The other option is just run everything as root and bypass all of those issues.

I love how on the two machines I installed Fedora 8 on, the installation by default has SElinux preventing rsyslogd from starting, because it’s not allowed to create /dev/log… Shouldn’t someone have noticed THAT? I was like, hmmm, the log is strangely empty here… And then (since there’s no log to look at) spending a day figuring out exactly what’s going on… Currently, it’s permissive… unlikely to change that.

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: