[3][4] The key concepts underlying SELinux can be traced to several earlier projects by the United States National Security Agency (NSA).

It includes a set of sample security policy configuration files designed to meet common, general-purpose security goals.A Linux kernel integrating SELinux enforces mandatory access control policies that confine user programs and system services, as well as access to files and network resources.

Limiting privilege to the minimum required to work reduces or eliminates the ability of these programs and daemons to cause harm if faulty or compromised (for example via buffer overflows or misconfigurations).

It has no concept of a "root" superuser, and does not share the well-known shortcomings of the traditional Linux security mechanisms, such as a dependence on setuid/setgid binaries.

The earliest work directed toward standardizing an approach providing mandatory and discretionary access controls (MAC and 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.

[citation needed] A comprehensive list of the original and external contributors to SELinux was hosted at the NSA website until maintenance ceased sometime in 2009.

For every current user or process, SELinux assigns a three string context consisting of a username, role, and domain (or type).

This system is more flexible than normally required: as a rule, most of the real users share the same SELinux username, and all access control is managed through the third tag, the domain.

The command runcon allows for the launching of a process into an explicitly specified context (user, role, and domain), but SELinux may deny the transition if it is not approved by the policy.

SELinux adds the -Z switch to the shell commands ls, ps, and some others, allowing the security context of the files or process to be seen.

Typical policy rules consist of explicit permissions, for example, which domains the user must possess to perform certain actions with the given target (read, execute, or, in case of network port, bind or connect), and so on.

Fedora Linux 10 introduced a minimum policy, designed for certain platforms such as low-memory devices and virtual machines.

[21] SELinux can potentially control which activities a system allows each user, process, and daemon, with very precise specifications.

Another popular alternative is called AppArmor and is available on SUSE Linux Enterprise Server (SLES), openSUSE, and Debian-based platforms.

There are several key differences: Isolation of processes can also be accomplished by mechanisms such as virtualization; the OLPC project, for example, in its first implementation[40] sandboxed individual applications in lightweight Vservers.

[41] General Dynamics builds and distributes PitBull Trusted Operating System,[42] a multilevel security (MLS) enhancement for Red Hat Enterprise Linux.