End systems must be able to enforce the separation of information based on confidentiality and integrity requirements to provide system security. Operating system security mechanisms are the foundation for ensuring such separation. Unfortunately, existing mainstream operating systems lack the critical security feature required for enforcing separation: mandatory access control (MAC) [17]. Instead, they rely on discretionary access control (DAC) mechanisms. As a consequence, application security mechanisms are vulnerable to tampering and bypass, and malicious or flawed applications can easily cause failures in system security.
DAC mechanisms are fundamentally inadequate for strong system security. DAC access decisions are only based on user identity and ownership, ignoring other security-relevant information such as the role of the user, the function and trustworthiness of the program, and the sensitivity and integrity of the data. Each user has complete discretion over his objects, making it impossible to enforce a system-wide security policy. Furthermore, every program run by a user inherits all of the permissions granted to the user and is free to change access to the user's objects, so no protection is provided against malicious software. Typically, only two major categories of users are supported by DAC mechanisms, completely trusted administrators and completely untrusted ordinary users. Many system services and privileged programs must run with coarse-grained privileges that far exceed their requirements, so that a flaw in any one of these programs can be exploited to obtain complete system access.
By adding MAC mechanisms to the operating system, these vulnerabilities can be addressed. MAC access decisions are based on labels that can contain a variety of security-relevant information. A MAC policy is defined by a system security policy administrator and enforced over all subjects (processes) and objects (e.g. files, sockets, network interfaces) in the system. MAC can support a wide variety of categories of users on a system, and it can confine the damage that can be caused by flawed or malicious software.
Traditional MAC mechanisms have typically been tightly coupled to a multi-level security (MLS) [7] policy which bases its access decisions on clearances for subjects and classifications for objects. This traditional approach is too limiting to meet many security requirements [8,9,10]. It provides poor support for data and application integrity, separation of duty, and least privilege requirements. It requires special trusted subjects that act outside of the access control model. It fails to tightly control the relationship between a subject and the code it executes. This limits the ability of the system to offer protection based on the function and trustworthiness of the code, to correctly manage permissions required for execution, and to minimize the likelihood of malicious code execution.
To address the limitations of traditional MAC, the National Security Agency (NSA), with the help of Secure Computing Corporation (SCC), began researching new ways to provide strong mandatory access controls that could be acceptable for mainstream operating systems. An important design goal for the NSA was to provide flexible support for security policies, since no single MAC policy model is likely to satisfy everyone's security requirements. This goal was achieved by cleanly separating the security policy logic from the enforcement mechanism. Through the development of two Mach-based prototypes, DTMach [12] and DTOS [20], the NSA and SCC developed a strong, flexible security architecture. Although high assurance was not a goal of the research, formal methods were applied to the design to help validate the security properties of the architecture [23,24]. Likewise, performance optimization was not a goal, but significant steps were taken in the architecture to minimize the performance overhead normally associated with MAC. NSA and SCC then worked with the University of Utah's Flux research group to transfer the architecture to the Fluke research operating system [25]. During the transfer, what has become the Flask architecture was enhanced to provide better support for dynamic security policies.
The NSA created Security-Enhanced Linux, or SELinux for short, by integrating this enhanced architecture into the Linux operating system. It has been applied to the major subsystems of the Linux kernel, including the integration of mandatory access controls for operations on processes, files, and sockets. NAI Labs has since joined the effort and has implemented several additional kernel mandatory access controls, including controls for the procfs and devpts file systems. The MITRE Corporation and SCC have contributed to the development of some application security policies and have modified utility programs, but their contributions are not discussed further in this paper.
Using the flexibility of SELinux, it is possible to configure the system to support a wide variety of security policies. The system can support:
The NSA released the SELinux to make the technology available to a wider community and enable further research into secure operating systems. To help introduce the system in a more immediately useful form that helps demonstrate the added value of SELinux, NSA contracted NAI Labs to develop an example security policy configuration for the system designed to meet a number of common general-purpose security objectives. The example configuration greatly reduces the complexity of SELinux that would otherwise be present if building the policy specification from scratch were required. The example configuration released with the SELinux provides a customizable foundation with which a secure system can be built.
The remainder of this paper describes SELinux. It begins by providing an overview of the Flask architecture and its SELinux implementation in Section 2. The security mechanisms added to the system are then described in Section 3. The SELinux application programming interface (API) is discussed in Section 4. Section 5 describes the example security policy configuration created for the system. The performance overhead of the SELinux mechanisms is described in Section 6. Related work is discussed in Section 7.