Creating SELinux Policies Simplified

Modern Linux distributions ship with a plethora of security features and tools, and one of the most important features added to the kernel has been the inclusion of SELinux.

SELinux solves one the most challenging problems in security. How to control trusted users or processes. Trusted users, such as root in the *nix domain, have unlimited and unrestricted access to a system. They should have, as this account is supposed to be used only by the system administrator; however, this leads to a problem. What happens if the root account itself gets hacked, leaving the hacker with complete control of the system. Malicious users are not the only problem; misconfiguration of a security tool, such as iptables, can have a profound effect as well. Besides this, imagine a security vulnerability is discovered for a service you deployed on your server, and no patch is made available in a timely manner. In this case, your system is vulnerable. SELinux secures Linux systems from these sorts of security issues by implementing mandatory access controls (MACs) in the Linux kernel. SELinux is based on the Flask security architecture. Discussion of the Flask architecture is avoided in this article, as excellent documentation about it is easily available on the Internet.

To understand mandatory access control, we must go through the currently deployed security model called discretionary access control (DAC). In a DAC system, access to objects is restricted based on their classifications. This type of control is discretionary in the sense that a subject with a certain set of access permissions is capable of passing those permissions on to another subject. For example, any program you run while logged on as a certain user has the same access rights that you have. Rights are set by another user (for example, root).

Any particular permission (read, write, execute and so on) can be thought of as a two-dimensional graph with users on one axis and objects on another. In essence, DAC systems check the validity of credentials presented to them against stored information.

As mentioned, the SELinux security model is mandatory access control, or MAC. This controls access in a different manner. Whereas DAC security models are authentication-based, MAC systems rely on authorization, not only of users but also of each object loaded by the system.

A MAC system controls objects individually and makes decisions on the rights and/or permissions of objects based on a security policy, which can define what rights the object should be accorded, based on different variables.

An example of how discretionary versus mandatory access control styles could affect the operation of a computer is a Python script. If the script allows an external entity to insert and execute malicious code on a computer system under a DAC system, the malicious code now has the same access rights as the code that executed it—the Python script.

A MAC system can restrict the rights of a certain process to only the resources needed for normal operation. A Python script may create a process (or it may be forbidden), but that process might not have the same set of permissions as the process that created it. Thus, the MAC approach is seen as secure.

In SELinux, the security policy configuration is defined in a text file written in the m4 language. It is compiled when the security policy is finalized and, at boot time, loaded into the memory. Only the security server can make policy decisions on the permissions of an object.

Security policy enforcement is done by components called object managers, which receive requests from client objects, submit queries to the security server and enforce the resulting decisions.

The SELinux implementation of the security server uses a combination of two security paradigms, called Type Enforcement (TE) and Role-Based Access Control (RBAC).

Type Enforcement makes security decisions based on what kind of object requests the permissions. For example, object types could include a regular file, a directory, a process or a socket. Type enforcement is an object labeling system that, combined with access mapping (from the domain of the object requesting permission and to the type of the object requested), returns a decision that defines the permissible actions of the object.

Role-based access control assigns permissions to objects in a computer system based on the role they play within that system. In practice, this means a process would have its permissions based on its parent process, the user logged on at the time and any number of other variables.

How processes, filesystem objects and sockets communicate with each other is defined by the security policy. In particular, the security policy governs how different types and roles may interact, along with any specific rules.

At present, SELinux provides binary compatibility with existing applications and source compatibility with kernel modules. The current implementation of SELinux is x86-specific.