Security-Enhanced Linux (SELinux) is a Linux feature that provides a variety of security policies, including U.S. Department of Defense style mandatory access controls, through the use of Linux Security Modules (LSM) in the Linux kernel. It is not a Linux distribution, but rather a set of modifications that can be applied to Unix-like operating systems, such as Linux and BSD. Its architecture strives to streamline the volume of software charged with security policy enforcement, which is closely aligned with the Trusted Computer System Evaluation Criteria (TCSEC, referred to as Orange Book) requirement for trusted computing base (TCB) minimization (applicable to evaluation classes B3 and A1) but is quite unrelated to the least privilege requirement (B2, B3, A1) as is often claimed. The germinal concepts underlying SELinux can be traced to several earlier projects by the U.S. National Security Agency.
(SELinux has been integrated into version 2.6 series of the Linux kernel, and separate patches are now unnecessary; the above is a historical quote.)
Security-Enhanced Linux is a FLASK implementation integrated in some versions of the Linux kernel with a number of utilities designed to demonstrate the value of mandatory access controls to the Linux community and how such controls could be added to Linux. Such a kernel contains architectural components prototyped in the Fluke operating system. These provide general support for enforcing many kinds of mandatory access control policies, including those based on the concepts of type enforcement, role-based access control, and multi-level security. Observers of operating system security research may recall DTOS, a Mach-derived Distributed Trusted Operating System, on which Flask was based, as well as Trusted Mach, a research project from Trusted Information Systems that was influential in the design and implementation of DTOS. Those interested in Type Enforcement may also be interested in Domain and Type Enforcement.
A Linux kernel integrating SELinux enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. This reduces or eliminates the ability of these programs and daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example). This confinement mechanism operates independently of the traditional Linux access control mechanisms. It has no concept of a "root" super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries).
The security of an unmodified Linux system depends on the correctness of the kernel, all the privileged applications, and each of their configurations. A problem in any one of these areas may allow the compromise of the entire system. In contrast, the security of a modified system based on an SELinux kernel depends primarily on the correctness of the kernel and its security policy configuration. While problems with the correctness or configuration of applications may allow the limited compromise of individual user programs and system daemons, they do not pose a threat to the security of other user programs and system daemons or to the security of the system as a whole.
From a puristic perspective, SELinux provides a hybrid of concepts and capabilities drawn from mandatory access controls, mandatory integrity controls, role-based access control (RBAC), and type enforcement architecture. Third-party tools enable one to build a variety of security policies.
It is also supported in EnGarde Secure Linux which requires registration to download.
There has been work on other distributions such as Familiar, but some of this was ceased due to technical reasons (the Familiar work was abandoned when SELinux needed extended attributes which were not supported in the JFFS2 filesystem).
The earliest work directed toward standardizing an approach toward provision of mandatory and discretionary access controls (MAC & DAC) within a UNIX (more precisely, POSIX) computing environment can be attributed to the National Security Agency's Trusted UNIX (TRUSIX) Working Group, which met from 1987 to 1991 and published one Rainbow Book (#020A) and produced a formal model and associated evaluation evidence prototype (#020B) that was ultimately unpublished. Sponsored by Chet Coates and Mario Tinto of the NSA's National Computer Security Center, and managed by Charles Testa of Infosystems Technology, the crucial architects of the TRUSIX project — and members of its Modelling Subcommittee — were Steve Bunch, Frank Knowles, Eric Roskos, Larry Wehr, and Bruce Wilner. (Testa and Wilner also briefly chaired the NSA Labelling Subcommittee — which counted among its membership to David Bell, Marv Schaefer, and Willis Ware — as well as building Trusted RUBIX, the only relational database management system to offer B2 functionality and assurance atop a B2 POSIX platform, partially under the auspices of the United States Air Force Rome Laboratory.) Their efforts, particularly as critics of the less technically profound work of the TRUSIX Access Control List (ACL) Subcommittee, survive in the IEEE POSIX 1003.6 "security extensions for portable operating systems environments" specification.
The AppArmor system generally takes a similar approach to SELinux. One important difference is that it identifies file system objects by path name instead of inode. This means that, for example, a file that is inaccessible may become accessible under AppArmor when a hard link is created to it, while SELinux would deny access through the newly created hard link. On the other hand, data that is inaccessible may become accessible when applications update the file by replacing it with a new version (a frequently used technique), while AppArmor would continue to deny access to the data. (In both cases, a default policy of "no access" avoids the problem.)
While there has been considerable debate about which approach is better, there is no strong evidence as of yet that one approach is preferable to the other.
Note also that existing access control mechanisms remain in place with either system.
SELinux and AppArmor also differ significantly in how they are administered and how they integrate into the system.
Isolation of processes can also be accomplished by mechanisms like virtualization; the OLPC project, for example, sandboxes individual applications in lightweight Vservers.