Security-Enhanced Fedora Core 2

First, some background on Security-Enhanced Linux, or SELinux for short. Developed by the US National Security Agency, Security-enhanced Linux is a research prototype of the Linux kernel with enhanced security. It contains new architectural components, which provide support for enforcement of mandatory access control policies that confine user programs to the minimum amount of privilege they require to do their jobs. In other words, users running SELinux can define explicit rules about what subjects (users and programs) can access which objects (files and devices). It can be thought of as an internal firewall with the ability to separate programs, thus ensuring a high level of security within the operating system. SELinux is distributed under GPL.

The concepts of mandatory access control have been incorporated into the 2.6 kernel series. This is perhaps one of the less glamorous aspects of the new kernel, interesting only to security experts and system administrators running mission critical servers. Yet, it is one of the most fundamental and far-reaching changes in the 2.6 kernel series and it will have major implications on the way we run Linux servers. Up until now, all default Linux kernels had a concept of a "superuser", with complete access to all files and devices on the system. This concept has now been modularized into several alternative security modules. While the concept of a superuser remains available, administrators will also be able to choose from one of the more restrictive modules at boot time, in which case certain programs and files will not be accessible to the superuser. Even if an attacker is successful in obtaining superuser privileges (as was the case in the recently compromised Debian machines), the attacker will not be able to modify the critical parts of the system - there is no such thing as "chmod 777" on a SELinux system.

Unfortunately, the kernel itself only provides the means for mandatory access control together with an example of how to create one's own access control policies. It is up to Linux distributions to create and implement a system that includes these controls and integrate them with the rest of the product. It is obvious that Red Hat's main goal is to include these controls into a future Red Hat Enterprise Linux release, but not before they are implemented and well-tested on Fedora Core, starting with the upcoming Fedora Core 2. This could be a major selling point of the company's enterprise line of products; of the major distributions, only Debian and Gentoo, both of which are non-commercial projects, have implemented SELinux functionality into their respective distributions.

How does this access control mechanism work in practice? On a standard Linux system not enhanced by SELinux, an attacker might get root privileges in cases where a program or process running as root is compromised (through buffer overflow or misconfiguration). If that happens, the attacker has unlimited access to the entire system. The situation is different on a system running SELinux with properly defined access control policies. If a program or process running as root is compromised, the damage is limited to whatever the process can access. Yes, trying to access files as root on an SELinux system can return "permission denied"!

This is what Red Hat/Fedora's role in the entire process is - write access control policies for applications and provide ways for users to customize these policies. The policies can get fairly complex and thorough understanding of the SELinux Policy Document is essential for effective use of the SELinux features. It will be interesting to see Red Hat's implementation of these policies and we will certainly revisit the subject once we've been through the first few weeks of Fedora Core 2 beta testing. For those who'd like to start looking into the subject straight away, this page provides an excellent collection of SELinux-related links.