Dealing with SeLinux
Young and Reckless
I'm not gonna lie to you. Prior to about a couple months ago, SeLinux was disabled on all my servers.
What can I say...I was young and reckless.
"I'll never need this"
"Oh, your documentation says turn off SeLinux...OK then. DONE!"
"Why the HELL is this website not showing up?! All the permissions are right. The service is up. The firewall is off. What is the problem-OH WAIT! It's SeLinux!"
Then Heartbleed happened. (That was Hell for me and I would not wish it on anyone)
Hindsight is 20/20
I've heard from a couple trusted sources that had SeLinux been enabled, Heartbleed would not have been an issue, or at least as big of an issue as it was. I believe the same goes for Shellshock, but I'm not sure.
Hearing that was enough for me to dive head first into SeLinux (after sobbing in a corner fighting flashbacks of the Heartbleed).
Now I've enabled it on all of my personal servers and new server builds. Needless to say, a lot of services broke. My Zabbix could no longer auto-discover some items, web services could no longer connect to their databases, and Apache could no longer write to some directories, just to name a few.
I expected breakage, and boy did I get it. Not to mention if you run with SeLinux disabled, then enable it, you could be playing the waiting game for a while when the server's files and folders are relabeled.
Hate Driven Learning
I started reading documentation, searching for HowTos on the interwebz, and trying my best to learn SeLinux at least enough to understand how to resolve issues related to it.
Then one night while the fiancée was at work, I started down a fevered (drunk) path to SeLinux nirvana in the form of my favorite (and first learned) scripting language.
BASH.
In a night filled with reading forum posts and other information on SeLinux, I
wrote a bash script that helps me automate troubleshooting of SeLinux issues.
In all actuality, it does nothing more than use existing tools
(audit2allow,checkmodule,semodule_package, and semodule) and some
simple (drunk) logic to automate it all into a single ./ (script).
The Gist of the Script (Not the Github Kind)
The script 'filters' the audit log based on a 'target', then runs audit2allow on the filtered log. From there it can create the source code for a new module and install said module if I so desire.
I know I have a few bugs due to the fact that sometimes other targets creep into the newly created module source code. That is to say, if I filtered on ruby, httpd items show up in the new module.
Also, there is the risk that I allow a program more access than it needs.
Once I think I've got a decent thing going, I may write another post explaining it in detail. If nothing else, it would be cool to have some feedback on it.
I Never Know How To End my Rants...
...so here is a link to a good article on SeLinux, plus slightly creepy picture from the same article.
I mean, that penguin looks kinda evil...right?
