SELinux: A PR problem?

The recent(ish) creation of http://stopdisablingselinux.com/ and @MajorHayden’s drive to get some love to SELinux have touched a nerve with many, myself included. Why is that?

SELinux is a noble project, as noble as the NSA get anyway, to define a set of things you can and can’t do in a very deliberate and fine grained way. The idea being, your webserver shouldn’t fire up /bin/sh and start poking around users home directories. Sounds grand? Who knows, no one ever gets so far as trying…

A PR Problem?

What do I mean PR problem? It’s just some kernel extensions, it’s not a celebrity! SELinux’s mission has hit a snag before it’s even begun. See @JordanSissel’s Tweetin' on it. I even have this in my .zshrc:

[ -e "/usr/sbin/selinuxenabled" ] && /usr/sbin/selinuxenabled && RPROMPT="%{$fg_bold[red]%} SELINUX%{$reset_color%}"

Alerting me in big (monospaced) red letters in my prompt if selinux is enabled on a machine I log in to.

Why all the negative energy on such a good sounding project? It’s because 90% (number pulled out of my bottom) of people’s first experience with SELinux is not “Oh cool, there’s this neat thing to make my machine much more secure and controlled” it’s “I’ve spent 6 hours trying to get this thing working! Why oh god doesn’t it work. OH MY FUNK SELINUX IS ENABLED. turns it off Now it works.”.

As the fifth biggest security hero, @DanKami once said, people only care about security if they’re getting something else. People would use clear text VPNs if it would get access to their stuff, they just don’t care. Most operations people, given the choice, of shipping or having it crazy secure and not shipping, would probably pick shipping, as that at least keeps them employed for another week. Your perfectly secure product that never shipped… doesn’t matter, it never shipped.

Negative much?

Perhaps, and if I am, I am sorry, but this is how I feel. Should I give SELinux a proper go? Absolutely. Will I? Unlikely. There are more interesting, much less tainted by history and experience projects that I would love to try much before this, which my mind just casts as a painful fight. Will I watch the Thomas Cameron’s at RedHat’s video on the subject before I say never? Yes. Is this just a rehash of Chris Siebenmann’s post? Probably, but this is what happens when you write before reading.

How to fix it?

Pivot? Kinda seriously, if it is a ‘brand’ problem. There’s so much negative thought in the operations and development community towards a system that is seen as a pain by most that would “killing it” and calling it FireBird, no Phoenix, no something else remove that? Or just leave the status quo as it is. Leaving it only used by Red Hat employees (and former employees) and infosec people with seemingly too much time on their hands/wanting to do a job properly. Or can we educate and/or automate our way out of this mess? Both Puppet and Chef have modules for enabling policy and people have even written ways of managing rules via such things Easily managing SELinux policies with puppet. Either way, it’s not going away/out of RHEL just yet, so we’re either going to have to embrace it, or carry on fighting it.