OStatic

Upgrading Your Linux Box? Read Up on SELinux, and Improve Security

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. I can thus keep my personal files hidden from other users by giving myself (the owner) read/write permissions, but by removing all permissions for group and other.

When I work on a project with other people, then I typically add all of us to the same group, and then make files readable and writable by that group, so that we can all modify them. This might sound simple in theory, but 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. I expect that SELinux will become the default for Linux security within the coming few years, as people become increasingly use to it, and begin to incorporate it into their default security policy.

If you're thinking of activating SELinux on your computer, or if you just want to learn more about it, there are many tutorials and articles on the Web. Here are a few of my favorites; feel free to add your own in the comments to this post.

• SELinux tutorial SELinux tutorial, with a nice explanation of the differences between SELinux and traditional Unix permissions
• Top 10 SELinux articles in 2007, as chosen by LinuxSecurity.com
• SELinux FAQ for Fedora Core, useful and interesting even if you use a different distribution.
• SELinux FAQ from the National Security Agency (NSA), which developed and released SELinux
• technical description of SELinux architecture -- not mandatory for using SELinux, but useful and interesting if you can follow it.

• linux
• security
• selinux

by an anonymous user on Aug. 21, 2008

I found SELinux to be more of a pain to set up, since it was enabled by default. Getting MySQL, etc. to work with SELinux ended up being more hassle than the security this provided. I can understand wanting to harden internet-facing machines, but for our LAN - I just disabled this sucker.

0 Votes

by an anonymous user on Aug. 22, 2008

I always disable it. Even packages that come with the distro don't work properly "out of the box" with SELinux turned on.

I used to think I was the only one that had problems with SELinux but over the last year I've seen many different boxes set up by many different admins and they all have it turned off or not compiled/enabled in the kernel.

0 Votes

Share Your Comments