 | |
 Screenshot of seinfo andsemanage showing SELinux information of a policy file used by the system, users of SELinux, and file labels related toSimple Desktop Display Manager | |
| Original author(s) | NSA andRed Hat |
|---|---|
| Developer(s) | Red Hat |
| Initial release | 22 December 2000; 24 years ago (2000-12-22)[1] |
| Stable release | |
| Repository | |
| Written in | C |
| Operating system | Linux |
| Type | Security,Linux Security Modules (LSM) |
| License | GNU GPL |
| Website | selinuxproject |
Security-Enhanced Linux (SELinux) is aLinux kernelsecurity module that provides a mechanism for supportingaccess control security policies, includingmandatory access controls (MAC).
SELinux is a set of kernel modifications and user-space tools that have been added to variousLinux distributions. Itsarchitecture strives to separate enforcement of security decisions from the security policy, and streamlines the amount of software involved with security policy enforcement.[3][4] The key concepts underlying SELinux can be traced to several earlier projects by the United States National Security Agency (NSA).
The NSA Security-enhanced Linux Team describes NSA SELinux as[5]
a set ofpatches to theLinux kernel and utilities to provide a strong, flexible, mandatory access control (MAC) architecture into the major subsystems of the kernel. It provides an enhanced mechanism to enforce the separation of information based on confidentiality and integrity requirements, which allows threats of tampering, and bypassing of application security mechanisms, to be addressed and enables the confinement of damage that can be caused by malicious or flawed applications. 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 anddaemons to cause harm if faulty or compromised (for example viabuffer overflows or misconfigurations). This confinement mechanism operates independently of the traditional Linux (discretionary) access control mechanisms. 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 onsetuid/setgid binaries.
The security of an "unmodified" Linux system (a system without SELinux) depends on the correctness of the kernel, of all the privileged applications, and of each of their configurations. A fault 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 necessarily 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 purist perspective, SELinux provides a hybrid of concepts and capabilities drawn from mandatory access controls,mandatory integrity controls,role-based access control (RBAC), andtype enforcement architecture. Third-party tools enable one to build a variety of security policies.
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 theNational Security Agency's Trusted UNIX (TRUSIX) Working Group, which met from 1987 to 1991 and published oneRainbow Book (#020A), and produced a formal model and associated evaluation evidence prototype (#020B) that was ultimately unpublished.
SELinux was designed to demonstrate the value of mandatory access controls to the Linux community and how such controls could be added to Linux. Originally, the patches that make up SELinux had to be explicitly applied to the Linux kernel source; SELinux was merged into theLinux kernel mainline in the 2.6 series of the Linux kernel.
The NSA, the original primary developer of SELinux, released the first version to theopen source development community under theGNU GPL on December 22, 2000.[6] The software was merged into the mainline Linux kernel 2.6.0-test3, released on 8 August 2003. Other significant contributors includeRed Hat,Network Associates,Secure Computing Corporation, Tresys Technology, and Trusted Computer Solutions. Experimental ports of theFLASK/TE implementation have been made available via theTrustedBSD Project for theFreeBSD andDarwin operating systems.
Security-Enhanced Linux implements theFlux Advanced Security Kernel (FLASK). Such a kernel contains architectural components prototyped in theFluke operating system. These provide general support for enforcing many kinds of mandatory access control policies, including those based on the concepts oftype enforcement,role-based access control, andmultilevel security. FLASK, in turn, was based on DTOS, a Mach-derivedDistributed Trusted Operating System, as well as on Trusted Mach, a research project fromTrusted Information Systems that had an influence on the design and implementation of DTOS.[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. The following list reproduces the original aspreserved by the Internet Archive Wayback Machine. The scope of their contributions was listed in the page and has been omitted for brevity, but it can be accessed through the archived copy.[7]
SELinux users and roles do not have to be related to the actual system users and roles. 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 circumstances under which a process is allowed into a certain domain must be configured in the policies. The commandruncon 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.
Files, network ports, and other hardware also have an SELinux context, consisting of a name, role (seldom used), and type. In the case of file systems, mapping between files and the security contexts is called labeling. The labeling is defined in policy files but can also be manually adjusted without changing the policies. Hardware types are quite detailed, for instance,bin_t (all files in the folder /bin) orpostgresql_port_t (PostgreSQL port, 5432). The SELinux context for a remote file system can be specified explicitly at mount time.
SELinux adds the-Z switch to the shell commandsls,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. More complex mappings are also possible, involving roles and security levels.
A typical policy consists of a mapping (labeling) file, a rule file, and an interface file, that define the domain transition. These three files must be compiled together with the SELinux tools to produce a single policy file. The resulting policy file can be loaded into the kernel to make it active. Loading and unloading policies does not require a reboot. The policy files are either hand written or can be generated from the more user friendly SELinux management tool. They are normally tested in permissive mode first, where violations are logged but allowed. Theaudit2allow tool can be used later to produce additional rules that extend the policy to allow all legitimate activities of the application being confined.
SELinux features include:
sestatus showing status of SELinux in a system (openSUSE Tumbleweed)SELinux has been implemented inAndroid since version 4.3.[12]
Among free community-supported Linux distributions,Fedora was one of the earliest adopters, including support for it by default since Fedora Core 2. Other distributions include support for it such asDebian as of version 9 Stretch release[13] andUbuntu as of 8.04 Hardy Heron.[14] As of version 11.1,openSUSE contains SELinux "basic enablement".[15]SUSE Linux Enterprise (SLE) 11 features SELinux as a "technology preview".[16]
SELinux is popular in systems based onLinux containers, such asCoreOS Container Linux and rkt.[17] It is useful as an additional security control to help further enforce isolation between deployed containers and their host.
SELinux is available since 2005 as part ofRed Hat Enterprise Linux (RHEL) version 4 and all future releases. This presence is also reflected in corresponding versions of derived systems such asCentOS,Scientific Linux,AlmaLinux andRocky Linux. The supported policy in RHEL4 is targeted policy which aims for maximum ease of use and thus is not as restrictive as it might be. Future versions of RHEL are planned to have more targets in the targeted policy which will mean more restrictive policies. RHEL version 5 introducedmultilevel security (MLS) policy for servers only. Fedora Linux 10 introduced a minimum policy, designed for certain platforms such as low-memory devices andvirtual machines.[18]
openSUSE Tumbleweed transitioned fromAppArmor to SELinux for new installation since 11 February 2025, upcoming SLE/openSUSE Leap 16 will be shipped with SELinux by default as well.[19] openSUSE/SLE adopted RHEL/Fedora policies for its SELinux implementation although with some differences.[20] AppArmor is retained for existing Tumbleweed and SLE/openSUSE Leap 15.x installation (users can manually migrate their existing installation to SELinux). AppArmor is also available as install-time selection for users who prefer it.[21]
SELinux can potentially control which activities a system allows each user, process, and daemon, with very precise specifications. It is used to confinedaemons such as database engines or web servers that have clearly defined data access and activity rights. This limits potential harm from a confined daemon that becomes compromised.
Command-line utilities include:[22]chcon,[23]restorecon,[24]restorecond,[25]runcon,[26]secon,[27]fixfiles,[28]setfiles,[29]load_policy,[30]booleans,[31]getsebool,[32]setsebool,[33]togglesebool[34]setenforce,semodule,postfix-nochroot,check-selinux-installation,semodule_package,checkmodule,selinux-config-enforcing,[35]selinuxenabled,[36]andselinux-policy-upgrade[37]
To put SELinux into enforcing mode:
setenforce 1To query the SELinux status:
getenforceSELinux represents one of several possible approaches to the problem of restricting the actions that installed software can take. Another popular alternative is calledAppArmor and is available onSUSE Linux Enterprise Server (SLES),openSUSE, andDebian-based platforms. AppArmor was developed as a component to the now-defunctImmunix Linux platform. Because AppArmor and SELinux differ radically from one another, they form distinct alternatives for software control. Whereas SELinux re-invents certain concepts to provide access to a more expressive set of policy choices, AppArmor was designed to be simple by extending the same administrative semantics used forDAC up to the mandatory access control level.
There are several key differences:
CAP_FOWNER orCAP_DAC_OVERRIDE. Under SELinux the administrator (or platform vendor) can configure SELinux to deny all capabilities to otherwise unconfined users, then create confined domains for the employee to be able to transition into after logging in, one that can exercise those capabilities, but only upon files of the appropriate type.[citation needed]Isolation of processes can also be accomplished by mechanisms such asvirtualization; theOLPC project, for example, in its first implementation[40]sandboxed individual applications in lightweightVservers. Also, theNSA has adopted some of the SELinux concepts in Security-EnhancedAndroid.[41]
General Dynamics builds and distributes PitBull Trusted Operating System,[42] amultilevel security (MLS) enhancement forRed Hat Enterprise Linux.
Multi-Category Security (MCS) is an enhancement to SELinux forRed Hat Enterprise Linux that allows users to label files with categories, in order to further restrict access through discretionary access control and type enforcement. Categories provide additional compartments within sensitivity levels used bymultilevel security (MLS).[43]
The NSA is pleased to announce that it has developed, and is making available to the public, a prototype version of a security-enhanced Linux operating system.
SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). Caching decisions decreases how often SELinux rules need to checked, which increases performance.
| Linux kernel | |
|---|---|
| Controversies | |
| Distributions | |
| Organizations | |
| Adoption | |
| Media | |
| Professional related certifications | |
Authority control databases: National |
|---|
