Secure Linux: Part 1. SELinux – history of its development, architecture and operating principles

History of SELinux

The project involving the development of Security-Enhanced Linux® (SELinux), a system offering mandatory access control, was initiated inside the US National Security Agency (NSA). The companies Secure Computing Corporation (SCC) and MITRE were directly involved in the development, along with a number of research laboratories. It was released as a general access software product (with the source code distributed under a GPL license) in December 2000. A special press release was issued by NSA to mark the occasion (see Related topics). By that time, 10 years had already been spent developing, analyzing, and testing the basic SELinux architecture as part of several semi-research/semi-military projects (see Project extravaganza: DTMach, DTOS, Fluke, Flusk, Flask).

Project extravaganza: DTMach, DTOS, Fluke, Flusk, Flask

In 1992–1993 researchers from NSA and SCC were working on creating the Distributed Trusted Mach (DTMach) operating system, which combined the results achieved from the TMach and LOCK projects. DTMach combined a generic type enforcement, a flexible access control mechanism, and a Mach microkernel. The DTMach project was then developed as part of the Distributed Trusted Operating System (DTOS) project. Once the DTOS project was complete, the efforts of NSA, SCC, and the University of Utah were combined to integrate the architecture of the DTOS security system into the Fluke research operating system. The new project was called Flux. In parallel, the security system’s original architecture was enhanced, enabling it to provide better support to dynamic security policies. The new enhanced architecture was called Flask. The next step involved NSA implementing this security system architecture for the Linux OS, with this being made available to the public under the name of Security-Enhanced Linux (see Related topics).

The new mandatory access control system was based on the process of checking the security labels of the operating system’s objects and subjects and included a number of the latest access control technologies. One of these technologies was type enforcement. This was initially tested in a specially designed, trusted "A1" level system known as LOCK (see LOCK), and then further developed in the security subsystem of the research operating system Flask. The use of type enforcement supports in particular implementation using SELinux role-based access control and Multi-Level or Multi-Category Security.

Type enforcement

Type enforcement is an access control technology where rights allowing the subject (user, software process and flow) access to the object (file, I/O port, and others) are granted according to the current security context or domain.

In SELinux the security context is stored in the extended file system attributes and is managed using the Linux Security Module (LSM). Type enforcement is required to implement Mandatory Access Control, supplements Role Based Access Control (RBAC), and is one of the first steps to Multi-Level Security (MLS) and Multi-Category Security (MCS).

LOCK

The aim of the LOCK project (Logical Co-processing Kernel), worked on at SCC, was to develop a trusted computer system providing multi-level security. This meant that the system had to meet "A1" requirements in accordance with the Trusted Computing System Evaluation Criteria (also known as the "Orange Book").

The project was successfully completed, resulting in several dozen systems being set up in military command centers. Type enforcement was the main architectural feature of LOCK technology, ensuring the effective implementation of the access control mechanism.

Basic LOCK technologies relating to security and access control (including type enforcement) are currently being developed in the following systems:

Sidewinder Internet Firewall product line

SELinux

See more detailed information about the LOCK project in Related topics.

When it was released, SELinux was distributed as an update to the 2.2 and 2.4 kernels. However, when the question was raised regarding whether SELinux would be included in the official kernel, Linus Torvalds asked for the project to be modified so that the Linux security subsystem could be implemented as a module to facilitate its subsequent maintenance or enhancement. As a result, the developers created the Linux Security Modules subsystem, providing the kernel functions with an interface for the security subsystem. This solution allows users and developers of Linux distributions to choose from a number of mandatory access control systems: AppArmor, TOMOYO Linux, SMACK, and SELinux.

Linux Security Modules

Linux Security Modules (LSM) is a Linux kernel subsystem designed to integrate into the kernel various security models implemented as modules. In 2001 NSA representatives at the Linux Kernel Summit suggested including mandatory control access system Security-Enhanced Linux in Linux kernel version 2.5. However, Linus Torvalds rejected this suggestion as SELinux was not the only security system being developed to increase Linux security. In addition to this, not all developers agreed that SELinux was the best solution. Instead of including SELinux directly in the kernel, the Linux Security Modules system was created, allowing security subsystems to be used as modules, which meant that it was relatively simple to connect new modules.

Development work on the LSM subsystem continued for roughly three years and it was included in the Linux kernel from version 2.6 onwards. The security modules currently officially being supported are SELinux, Apparmor, Smack, and TOMOYO Linux.

A detailed description of the LSM architecture is provided in the article "Linux Security Modules: General Security Support for the Linux Kernel" (see Related topics), presented at the USENIX Security conference in 2002.

SELinux relates to mandatory access control systems based on label control. This means that every object or subject in the operating system protected by SELinux needs to have its own special label called a security context. These labels were initially stored as numbers in the unused fields in the ext2 file system’s nodes. Each numerical label was mapped in SELinux to a human-readable text-based security context label. This approach was not scalable and was based on the features of the specific ext2 file system, with this being regarded as an obvious drawback with the whole solution.

During the next phase of its development, SELinux was implemented as a module that could be loaded into Linux kernel version 2.4. The module operated with labels being stored in a separate file, which meant that this SELinux implementation had no restrictions with regard to the file system being used. However, removing one architectural flaw resulted in another one appearing. The frequent access made to the file containing the security context labels led to a sharp drop in productivity.

The problem was finally resolved with the release of Linux kernel version 2.6, with the full support of Linux Security Modules and the extended attributes in the ext3 file system. To be able to store the security context labels for the system’s objects and subjects, SELinux switched to using extended attributes. Unfortunately, this innovation again resulted in restrictions involving the use of the file system. SELinux could only be used in file systems that supported extended attributes. However, this problem began to subside over time and now virtually all commonly used file systems have full support for extended attributes, meaning they can be used with SELinux.

Some time later SELinux was integrated into the Linux kernel and started to be distributed for testing for the first time as a subsystem of the kernel 2.6.0-test3, released on August 8, 2003. As part of this, a kernel patch was released for kernels 2.2 and 2.4 for the mandatory access control system, while the introduction of support for Linux Security Modules in kernel 2.4 led to the launch of a SELinux version for LSM.

SELinux very quickly became the de facto standard in protected Linux systems and one of Red Hat Enterprise Linux’s most popular corporate distributions (starting with Red Hat Enterprise Linux 4). After this, SELinux began to be used in the widely deployed Debian and Fedora OS and was supported by the Ubuntu distribution which had grown in popularity (from LTS version 8.04 Hardy Heron). Much later, Novell (which was developing AppArmor at that time and had plans to include it in the Linux kernel) began to support SELinux in its OpenSUSE and SUSE Linux Enterprise distributions.

Eventually, Security-Enhanced Linux was supported by the developers of all the popular distributions. In the current Linux kernel version 2.6, SELinux uses Linux Security Modules to operate. In addition to this, many SELinux elements have been incorporated into the actual kernel.

The lengthy path which the development of this mandatory access control system has taken has been overseen by the US National Security Agency. The basic work involved in integrating SELinux into the Linux kernel was also supported by Red Hat. A detailed list is given on the NSA website of the developers who have made the most significant contribution to the development of SELinux (see Related topics).

SELinux architecture

As mentioned above, the SELinux system inherited the architecture of the security subsystem from the research operating system Flask. Flask’s main feature was that it used the "least privilege" concept to grant users or applications only those access rights required to perform the requested actions. This concept is implemented using type enforcement (see Type Enforcement), thanks to which mandatory access in SELinux operates as part of the domain-type model. In this model each process subject is launched in a defined security context (domain) (that is, it has a certain access level), while all the operating system’s resource objects (files, directories, sockets, and others) have a certain type (secrecy level) associated with them.

Thanks to type enforcement, SELinux’s access control options significantly exceed the options offered by the basic discretionary access control model used in UNIX®-type systems. For example, SELinux can be used to strictly limit the network port number which the network server will be able to access. It can also allow individual files to be created and have data saved in them, but not to be deleted, etc. This grading of operating system objects helps restrict system and user processes using the set of access rights clearly assigned to specific resources. If any of the services controlled by SELinux is compromised, the intruder will not be able to get beyond the sandbox, which is restricted by the set of rules, even with superuser rights.

The list of rules defining permissions for allowing certain domains to access certain types is also a security policy. The security policy is applied once when the system is set up and consists of a set of text files which are loaded in the Linux kernel’s memory during system start-up.

The rules are in a human-readable form and can be understood even by ordinary users. For example, in the rule shown below for the http server domain, permission is given to read some files containing the network configuration:

allow httpd_t net_conf_t:file { read getattr lock ioctl };

SELinux inherited the structure and principle for operating labels defining the security context of the operating system’s objects and subjects, along with the "domain-type" model, from the Flask security subsystem. To ensure total protection, the security contexts must be defined for each object and each subject in the system. The labels come in the following form:

<user>:<role>:<type>

For example, the label for the distributed security context takes the form: system_u:object_r:httpd_exec_t. In SELinux, the user system_u is usually the default name for the system’s daemons. The role object_r is assigned to system objects such as ordinary files or devices. The httpd_exec_t type is applied to the httpd file being executed, located at the address /usr/sbin/httpd. The user , role , and type elements will be discussed in more detail in the next article.

Figure 1. Overview of the mandatory access control system using SELinux

SELinux comprises five basic components:

Auxiliary modules for operating with the file system

Modules for interacting with the Linux Security Modules event hook

A basic mechanism for organizing access control

Policy Enforcement Server, a system security policy database

Access Vector Cache (AVC), an auxiliary mechanism for increasing productivity

SELinux’s operation is organized as follows:

The operating system subject (process) attempts to perform a certain action on a particular object (file, process, socket), which is permitted within the Linux standard discretionary security system (DAC). This launches a stream of requests to the object. Every request to perform the action with the object is intercepted by the Linux Security Modules and is transferred, along with the subject’s and object’s security context, to the SELinux Abstraction & Hook Logic subsystem, which is responsible for interaction with LSM. The information received from the SELinux Abstraction and Hook Logic subsystem is forwarded to the basic Policy Enforcement Server module, which is directly responsible for making the decision about allowing the subject to access the object. To receive the decision as to whether the action is allowed or prohibited, the policy enforcement server contacts the special Access Vector Cache subsystem, which most often caches the rules being used. If AVC does not contain the cached decision for the relevant policy, the request for the necessary security policy is forwarded again to the security policy database. When the security policy has been found, it is transferred to the policy server receiving the decision. If the requested action complies with the policy that has been found, the operation is permitted. Otherwise, it is prohibited and all the decision-making information is written to the SELinux log file.

As well as making the decision about allowing or prohibiting certain actions, the Policy Enforcement Server module is also responsible for carrying out auxiliary tasks such as security label management (allocation, removal).

As is the case with excellent systems, the simplicity of SELinux’s operation must ensure reliable operation, a low demand for resources, and a good level of productivity from the entire mandatory access control system.

Conclusion

This article from the "Secure Linux" series kicks off with a discussion of Security-Enhanced Linux—the best-known and most powerful mandatory access control system used in the GNU/Linux operating systems.

SELinux deserves its reputation as a reliable security protection system. The standing of the US National Security Agency, which created and developed SELinux, has greatly contributed to this. However, apart from the NSA’s authoritative contribution, SELinux is also based on many years of scientific development in the field of IT system security. These developments have an in-depth theoretical basis and have proved themselves to be highly effective in practice in specialized military systems.

However, it is still not that simple to use SELinux in corporate networks or in home PCs. SELinux relates to label-based mandatory access control systems, which specifically means that each operating system object and subject must be assigned a label—a security context. Finally, on average, a good SELinux security policy for the whole system contains more than 100,000 rules! As a result, creating, refining, and maintaining it in its current form take up far too much time and effort. Creating such a security policy from scratch for an existing or planned computer system is in fact only justified in very few cases, if, for instance, the nature of the data being stored and processed requires exceptional reliability and protection from the server. Critics of the system say that SELinux is only so impenetrable from an IT security perspective due to its complexity. For instance, if an intruder was able to get round the system’s defense, the excuse might be given that the administrator set up SELinux incorrectly.

When attempting to devise access rules for any particular program, the administrator may also come across actions disregarding SELinux’s restrictions. For example, some applications in Linux partially switch from superuser rights to ordinary user rights and vice versa; that is to say, they try to apply the least privilege principle – the superuser’s rights are in fact only used when absolutely necessary. However, it is not easy to describe such behavior as being part of the SELinux security model.

Progress continues, however, and all these issues are under the constant scrutiny of developers. Some complete sets of rules have been created which can be used in typical situations on servers and home PCs: the system administrator simply has to select one of the ready-made security policies and reboot the computer with SELinux activated.

SELinux itself is also constantly being improved, both through the creation and development of security policies and through interaction with developers and modifying existing programs.

Additional articles in the "Secure Linux" series give a detailed description of how SELinux is used in practice, which entails creating and refining rules, controlling how SELinux behaves, and resolving possible problems.

Downloadable resources

Related topics