The benefit of SELinux is twofold. First, it replaces the user-based model with a policy-centric model. Every action, like running an application or reading and modifying data, is controlled by a security policy. Actions that violate the policy are denied. Additionally, SELinux compartmentalizes the various applications and processes running on the system. This not only helps in isolating a break-in, but also confines the damage caused by one compromised service.
SELinux plugs into the Linux distribution through the Linux Security Module (LSM) hooks, which are available in the 2.6.x kernel series. LSM was designed to integrate security models to work with the kernel, instead of applying them as a patch.
The SELinux way of life
At the core of SELinux is its policy. When the National Security Agency (NSA) handed over SELinux to the open source community, they just had one policy called the strict policy. The strict policy follows the concept of a whitelist, meaning that the default policy is to deny applications access unless they’re specifically allowed.
This policy shipped with Fedora Core 2. In FC2, SELinux locks down everything and the strict policy is a collection of Allow statements. But such a policy needs regular maintenance and has to be kept updated with every change to the configuration of the system. So, if you install new applications or use an existing application in a way the policy writer didn’t predict, the strict policy would complain. The strict policy works best in a controlled, restricted environment but not at all well on a regular desktop.
| Managing SELinux in Fedora Core 6 – click to view |
To overcome the issues of the strict policy, Fedora Core 3 introduced the targeted policy. In contrast to the strict policy, a targeted policy is a list of ‘Deny’ statements. Under it, by default SELinux allows all actions, which gives a desktop user the freedom to use the system as if SELinux wasn’t turned on. And yet by restricting only certain targeted applications, it’ll protect the critical network daemons. This policy also made its way into Red Hat Enterprise Linux (RHEL) 4.
That’s also when the SELinux engineers at Red Hat turned their attention towards performance tuning. The SELinux Fedora Core 5 FAQ claims a 7% impact on performance when it was last benchmarked. I tried SELinux on Fedora Core 6, which boasts of several performance enhancements and there wasn’t any noticeable difference in performance with or without SELinux enabled.
Type enforcement
Going a little deeper, SELinux’s policies are actually based on the access control concept of Type Enforcement (TE). TE uses a “security context” attribute to make its access decisions. Under SELinux this security context has three elements, user, role, and type.
Now, TE uses an access matrix that contains rules about clearance. These are required to grant the different users and programs called subjects, rights over files, sockets, and network hosts, called objects, by matching their security context. So, for example, this is how SELinux determines if an application X (subject) is allowed to write (action) to the file Y (object).
SELinux modifies several common system utilities so that they can display the security context of the objects and subjects with the -Z option. For example, ls -Z will display the security context of the file system objects in the current directory, id -Z will display the security context of the user and ps -Z will display the security context of the current processes.
So how does it all translate into a policy file? Here’s a rule from a targeted policy:
allow user_t bin_t : file {read execute getattr};
Here, applications with the type user_t (subject) are allowed to read, execute, and get attributes for all objects of class files that have the type bin_t in their security context.
The rule only applies to those file objects that have the type bin_t. It doesn’t apply to objects that are of bin_t type but not of file class and neither to file objects that do not have bin_t as their type. It may seem confusing, but one has to appreciate the level of control SELinux allows.
Making SELinux easier to work with
I have written about SELinux earlier and the basics still remain the same. But policies are where the rubber hits the road, and they have been evolving with every release. Fedora Core now ships with targeted policies to cover all major network services. Additionally, SELinux under FC6 includes a new Multi-Category Security (MCS) policy based upon the Multilevel Security (MLS) access control mechanism. By tagging security labels on files, MLS can categorize them with different sensitivities.
| The setroubleshoot utility – click to view |
Auditing support in SELinux is also being worked on. Access Vector Cache (AVC) messages are the audit messages generated by SELinux as a result of access denials, but many admins had a difficult time making sense of all the “avc: denied” messages filling up their system logs in FC2/FC3. Now, admins have several easy to use tools to make sense of all the SELinux audit messages.
Tresys bundles several graphical and command-line tools for policy and audit message analysis in its SETools package. Another useful tool is the SELinux Troubleshooter that debuted in FC6. It scans the audit logs looking for AVC messages. When it finds one, it alerts the user with a brief and easy to follow description of the denial, and also suggests a fix.
Still, understanding and creating a new custom SELinux policy is not child’s play. The reference policy is designed to be an easy to use and understand base to write new policies. FC5 uses policies based on this schema. SLIDE is an Integrated Development Environment (IDE) that plugs into the Eclipse SDK and helps in creating a policy based on the reference policy.
Conclusion
SELinux is a very mature product. NSA had been working on it for several years before releasing it to the Open Source community in December 2000. Even now it has been worked on by many individuals and companies. People in charge of application and data security will appreciate SELinux’s robustness in dealing with zero-day exploits and poorly designed applications. Red Hat and Tresys both seem to be pretty interested in making SELinux easy to use and manage. Apart from RHEL and Fedora Core, users of Gentoo, Debian, and Ubuntu can also reap the benefits of SELinux.
In addition to people interested in securing their desktop or their enterprise computer, SELinux is a good subject for students studying operating system security. While it does take some getting used to, SELinux is here to stay and keep watch.
SELinux is a vast topic, and the idea of this article is to give you an overview of SELinux’s access control features and to show its level of control. If you are interested in diving deeper into SELinux, you might want to refer to the SELinux FAQ and to one of the several books written on the topic.
