SELinux - a practical guide

originally from: ostatic.com

I just spent several days helping to upgrade an organization's servers from Red Hat Enterprise 3 to the latest version, Red Hat Enterprise 5.2. There were, of course, a large number of differences between the two versions; it's probably safe to say that every program and library underwent a significant upgrade. But one of the most important, and impressive, differences between the two was its use of SELinux, or "security-enhanced" Linux.SELinux offers a great deal of functionality, and helps to protect Linux boxes from a variety of threats. It forces system administrators to learn a new vocabulary, as well as permissions, logfiles, and programs with which they were previously unfamiliar. Fortunately, there are many good tutorials for SELinux on the Web. If you're interested in protecting your Linux boxes, you should take a look at these -- preferably before you perform any upgrades. SELinux is available as part of a growing number of distributions, and it has the potential to make your system significantly more secure.I've long told people that "all Unix problems are permission problems," and that's largely the case: Each Unix file (or program) traditionally belongs to a single user and a single group. The file can then be assigned read, write, and/or execute permission for the user, the group, or everyone on the system.

Unix system administrators know that getting permissions right can often take time. The thing is, Unix permissions are the only thing that stop an intruder from doing something nasty. If someone is able to gain access to your "root" (superuser) account, then they can do whatever they want, because Unix systems typically ignore permissions for the root user. If a program that runs as root has a security hole, then it might be possible to exploit that hole, using the program to execute program with the root user's permissions. Programs that run as users other than root aren't quite as dangerous, but they can still cause considerable damage.
SELinux solves these problems by adding a second layer of security, which takes effect where the traditional Unix permissions would permit access. Instead of just assigning user and group permissions, SELinux has a huge number of very specific access types. So a file might be described as a "file in /etc," or "a program in /bin," or "a file to be served by the HTTP server." Only a user who has been given explicit permission to access a file of that type will be allowed to do so.As impressively secure as SELinux can be -- actual security is, of course, a matter of policy and vigilance, not a single technology --

I was even more impressed by the tools that make it possible to work with SELinux. SELinux logs every access success and failure, making it possible to find (and understand) what is happening behind the scenes.When something does go wrong, the program audit2why can give an explanation, and the program audit2allow can produce a file that changes the current system policy, in order to allow access. Of course, you might not want to change the the system policy at all, but rather change the type of a file; the "chcon" program can do that, much as "chmod" works for regular permissions.Working with SELinux can be difficult and annoying at first, since it initially seems as though a huge number of programs are forbidden from doing innocuous things. Not only does SELinux become easier to work with over time, but the included programs make it possible to zero in on problems and fix them in a relatively short time. After a while, it becomes fairly natural to work with SELinux.

read more