Security-Enhanced Linux

Security-Enhanced Linux (SELinux)

Company type	Security module
Industry	Computer security, Operating systems
Founded	December 22, 2000 (2000-12-22)
Founder	United States National Security Agency (NSA)
Products	Mandatory access control framework for Linux kernel
Parent	Linux kernel

Security-Enhanced Linux (SELinux) is a Linux kernel security module designed to implement access control policies, including mandatory access control (MAC) mechanisms.

SELinux integrates kernel modifications with user-space utilities and is included in numerous Linux distributions. Its design distinctly separates the enforcement of security decisions from the underlying security policy, simplifying the complexity involved in policy implementation. This technology was developed through initiatives led by the United States National Security Agency (NSA), focusing on strengthening security management within Linux systems.

Overview

According to the NSA Security-enhanced Linux Team, NSA SELinux is described as

a collection of patches applied to the Linux kernel and associated utilities, delivering a robust and adaptable mandatory access control (MAC) framework across key kernel subsystems. It enhances the enforcement of information separation based on confidentiality and integrity criteria, addressing risks related to tampering and circumventing application security measures, thereby containing potential damage caused by malicious or defective applications. Additionally, it provides sample security policy configuration files intended to support common, general-purpose security objectives.

A Linux kernel equipped with SELinux enforces mandatory access control policies that restrict user applications and system services, as well as regulate access to files and network resources. By limiting privileges strictly to what is necessary, SELinux minimizes or eliminates the potential harm from malfunctioning or compromised programs and daemons (for example, due to buffer overflow vulnerabilities or misconfigurations). This confinement operates independently from conventional Linux (discretionary) controls and does not rely on a "root" superuser concept, thereby avoiding typical vulnerabilities associated with setuid/setgid executables.

The security integrity of a standard Linux system depends heavily on the correctness of its kernel, privileged applications, and their configurations; any flaw in these components can jeopardize the entire system. Conversely, an SELinux-enabled system primarily depends on the accuracy of the kernel and its configured security policies. In this model, faults within applications are contained, limiting risk to individual programs or daemons without endangering overall system integrity.

SELinux merges principles from mandatory access controls, mandatory integrity controls, role-based access control (RBAC), and type enforcement architecture. Various third-party tools facilitate the creation of diverse security policy frameworks.

History

Initial attempts to establish standardized models for mandatory and discretionary access controls (MAC and DAC) within UNIX systems date back to the Trusted UNIX (TRUSIX) Working Group led by the National Security Agency between 1987 and 1991. This group developed formal frameworks and prototype evaluations.

SELinux was created to highlight the benefits of mandatory access controls to the Linux user base. At first, SELinux required manual patching; however, it was eventually integrated into the Linux kernel mainline starting from version 2.6.

The NSA, as the original main developer, made SELinux available under the GNU GPL license on December 22, 2000. It became part of the mainline Linux kernel with version 2.6.0-test3 on August 8, 2003. Significant contributors include Red Hat, Network Associates, Secure Computing Corporation, Tresys Technology, and Trusted Computer Solutions. Experimental implementations of the FLASK/Type Enforcement model are accessible through the TrustedBSD Project for both FreeBSD and Darwin platforms.

Security-Enhanced Linux incorporates the Flux Advanced Security Kernel, whose design originates from prototype systems in the Fluke operating system. FLASK facilitates enforcement of multiple mandatory access control policies such as type enforcement, Role-Based Access Control (RBAC), and multilevel security. The FLASK architecture draws influence from DTOS—a Mach-based Distributed Trusted Operating System—and Trusted Mach developed by Trusted Information Systems.

Original and external contributors

Until 2009, a detailed roster of both primary and external contributors to SELinux was maintained on the NSA’s website. This list remains accessible via the Internet Archive Wayback Machine. Specific contribution information is preserved there but omitted here for conciseness.

Users, policies and security contexts

In SELinux, each user or process is assigned a security context consisting of three components: username, role, and domain (or type). Generally, most actual users share a common SELinux username, while domain identifiers primarily govern access control. Policy definitions determine when processes are permitted to transition into specific domains. The runcon utility enables launching processes within designated contexts, provided such transitions comply with policy rules.

SELinux also assigns security contexts—comprising name, role (seldom utilized), and type—to files, network ports, and hardware devices. File system labeling associates files with security contexts defined by policy but can be modified manually if needed. Hardware types are specifically categorized—for example, bin_t applies to /bin directory files, while postgresql_port_t corresponds to PostgreSQL’s port 5432. Contexts for remote file systems can be specified during mounting.

The functionality of commands like ls and ps is extended by SELinux through the -Z option, which reveals security context information.

Policies explicitly define permissions by specifying which domains users require for operations such as reading, executing, binding, or connecting. These policies can incorporate intricate mappings involving roles and security clearances.

A standard policy consists of labeling directives, rule sets, and interface files that govern domain transitions. These components are compiled into a unified policy file that is loaded into the kernel dynamically without requiring a reboot. Policies may be authored manually or generated using SELinux management utilities and are often initially deployed in permissive mode to log violations without enforcing restrictions. The audit2allow tool assists in creating supplementary rules to accommodate legitimate application behaviors.

Capabilities

The capabilities of SELinux encompass:

• Distinct separation between policy definition and enforcement mechanisms
• Clearly established interfaces for policy interaction
• Functionality allowing applications to query policies and enforce access controls, such as ensuring crond jobs operate within the correct security context
• Independence from particular policy frameworks, languages, or security-label formats
• Unique labels and access controls assigned to kernel objects and system services
• Ability to modify policies dynamically during runtime
• Separate safeguards addressing system integrity (domain-type) and data confidentiality (multilevel security)
• Granular policy enforcement over process creation, inheritance, execution, file systems, directories, individual files, open file descriptors, network sockets, inter-process messages, network interfaces, and capability management
• Use of the Access Vector Cache (AVC) to store access decisions for performance optimization
• A default-deny approach—access requests are rejected unless explicitly authorized

Deployment

Since Android 4.3, SELinux has been incorporated into the Android platform.

Among community Linux distributions, Fedora was an early adopter with SELinux enabled by default starting from Fedora Core 2. Other distributions supporting SELinux include Debian (introduced in version 9 Stretch) and Ubuntu (since 8.04 Hardy Heron). Starting with version 11.1, openSUSE offers basic SELinux support, while SUSE Linux Enterprise 11 features it as a "technology preview."

SELinux is extensively utilized in containerized Linux environments such as CoreOS Container Linux and rkt to strengthen container isolation.

From version 4 onward, SELinux has been integrated into Red Hat Enterprise Linux (RHEL), with all subsequent releases including it. Distributions derived from RHEL like CentOS, Scientific Linux, AlmaLinux, and Rocky Linux also incorporate SELinux. The default targeted policy in RHEL strikes a balance between security and usability; more stringent policies are planned for future releases. RHEL 5 introduced multilevel security policies tailored for server environments. Fedora Linux 10 added a minimal policy designed specifically for devices with limited memory and virtual machines.

On 11 February 2025, openSUSE Tumbleweed switched its default security framework from AppArmor to SELinux for new installations; the forthcoming SLE/openSUSE Leap 16 release will also include SELinux enabled by default. The openSUSE/SLE projects adopted SELinux policies based on those from RHEL/Fedora but with some modifications. AppArmor remains accessible for current Tumbleweed and SLE/openSUSE Leap 15.x users and is offered as an installation option for those who prefer it.

Application scenarios

SELinux facilitates detailed governance over system operations involving users, processes, and daemons, making it particularly effective for isolating services such as database servers or web servers with clearly defined data access permissions. This containment strategy mitigates potential damage from compromised services.

Important command-line tools include:chcon, restorecon, restorecond, runcon, secon, fixfiles, setfiles, load_policy, booleans, getsebool, setsebool, togglesebool, setenforce, semodule, postfix-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing, selinuxenabled, and selinux-policy-upgrade.

Usage Examples

To activate SELinux enforcing mode, execute:

setenforce 1

To verify the current SELinux status, use:

getenforce

SELinux versus AppArmor

SELinux represents one method for controlling software behavior, with AppArmor serving as a widely adopted alternative on platforms such as SUSE Linux Enterprise Server, openSUSE, and Debian-based distributions. Originating from the discontinued Immunix Linux system, AppArmor fundamentally differs from SELinux in both architecture and policy flexibility.

Notable distinctions include:

• AppArmor relies on file pathnames rather than inode identifiers to recognize filesystem objects. For instance, access might be granted when a hard link is created under AppArmor but denied under SELinux.
  • As a result, AppArmor does not implement type enforcement; instead, configuration files reference files directly without assigning types.
• The management approach and integration with the operating system vary considerably between the two frameworks.
• AppArmor builds upon traditional discretionary access control (DAC) semantics at the mandatory access control (MAC) layer, offering a limited set of operations—read, write, append, execute, lock, and link—in contrast to SELinux’s broader capabilities including mknod creation, network socket binding, POSIX capability handling, kernel module management, and shared memory controls.
• Unlike SELinux, AppArmor cannot categorically restrict POSIX capabilities. While it can prevent changes to its own policies and control mounting/unmounting of filesystems, it does not limit users from operating outside defined control domains.
  • For example, SELinux permits administrators to revoke all capabilities from unconfined users while allowing confined domains to possess specific capabilities restricted to suitable file types.
• AppArmor does not support multilevel security frameworks such as Bell–LaPadula or Biba models.
• Configuration methods differ: AppArmor exclusively employs flat configuration files, whereas SELinux combines flat policy files with extended filesystem attributes for enforcement purposes.
• SELinux offers centralized policy management through a "remote policy server" configurable via /etc/selinux/semanage.conf. In contrast, centralized administration of AppArmor is more challenging due to its requirement for root-level deployment or manual server setup.

Related Technologies and Enhancements

Virtualization also provides process isolation; for example, the OLPC project initially sandboxed applications using lightweight Vservers. The NSA has incorporated SELinux principles into Security-Enhanced Android.

General Dynamics offers PitBull Trusted Operating System, an MLS (multilevel security) enhancement tailored for Red Hat Enterprise Linux.

Multi-Category Security (MCS), an SELinux extension available in Red Hat Enterprise Linux, allows files to be labeled with categories that enforce discretionary access control alongside type enforcement. This introduces compartments within MLS sensitivity tiers.

External links

• Security-Enhanced Linux archived by the National Security Agency on the Internet Archive