Re-Enabling SELinux Training

This morning, I’m attending Rik Farrow’s “Working with SELinux” course. As soon as I walked into the room, it became apparent that I’m in the right place. On the screen was the lead slide of Rik’s show, and the title was “Re-enabling SELinux”. For me, that’s so appropriate, because one of the items on my “new machine” checklist is “disable SELinux”. To me, it’s always been a source of irritation that stopped me from performing actions necessary to administer the machine. The most frustrating part was always that I knew it didn’t have to be like that. I knew that SELinux could be a boon to admins who are always concerned with security. I just didn’t know how to make it work.

SELinux is a extension to the Linux code that was developed by the United States Department of Defense and was released to the Linux community in 2000. It was designed to subscribe to the idea of MLS – multi-level secure. This allows for the categorization of various security levels, such as “secret” or “top-secret”. Most system administrators aren’t concerned so much about “secret” and “top secret” so much as “secure” and “vulnerable”, though.

We can use SELinux’s type enforcement to achieve more secure systems. Contexts are assigned to a multitude of operations and objects, and we constrain them using policies that constrain attempted actions.

The tools used to manipulate SELinux aren’t numerous, but the number of contexts is immense. The hardest part sounds like keeping track of what the contexts should be. Fortunately, SELinux includes ways for us to debug our configuration., such as “setroubleshoot”, which takes the log output of SELinux and formats it so that normal humans can understand it. Audit2allow takes audit log messages and converts them into policy statements, so that perceived failures turn into allowed actions. There are also other ways of configuring SELinux so that it’s useful before it’s really in place.

If you have administered a Linux machine, you may have noticed that there are three possible modes for SELinux. The first is “disabled”, and if you’re like many of the people in the class, this is the one your machines are set to.

The second, “permissive” is much better. This allows SELinux to run and watch access attempts, but not to actually constrain them. This de-fanged mode allows us to see what SELinux would have denied, and change our configuration to allow it, or reconfigure the application as necessary.

The third, “enforcing” is the real mode, which not only watches access attempts, like the “permissive” mode, but also prevents access. Once your configuration is correct, switching from “permissive” to “enforcing” doesn’t require a reboot, only a setenforce command.

After completing this training, I’m very much looking forward to working with it on my machines. My new machines are no longer going to default to “Disabled SELinux”. Instead, I’m going to start evaluating how I can leverage the extra security that it gives.

Rik Farrow's SELinux Training http://www.usenix.org/event/lisa09/training/tutonefile.html#m8