Editing Security-Enhanced Linux

{{short description|Linux kernel security module}}{{Use dmy dates|date=February 2025}}{{Infobox software
| name = SELinux
| logo = SELinux logo.svg
| logo caption = 
| logo_size = 210x232px
| logo_alt = 
| screenshot = SELinux seinfo and semanage screenshot.webp
| caption = Screenshot of <code>seinfo</code> and <code>semanage</code> showing SELinux information of a policy file used by the system, users of SELinux, and file labels related to [[Simple Desktop Display Manager]]
| screenshot_size = 
| screenshot_alt = 
| collapsible = 
| author = [[NSA]] and [[Red Hat]]
| developer = [[Red Hat]]
| released = {{Start date and age|2000|12|22|df=yes}}<ref>{{cite web
 | title      = Security-enhanced Linux available at NSA site - MARC
 | url      = https://marc.info/?l=linux-kernel&m=97749381725894
 | website      = [[MARC (archive)|MARC]]
 | access-date      = 24 December 2018
 | archive-date      = 17 March 2019
 | archive-url      = https://web.archive.org/web/20190317053151/https://marc.info/?l=linux-kernel&m=97749381725894
 | url-status      = live
 }}</ref>
| discontinued = 
| latest release version = 3.6
| latest release date = {{Start date and age|2023|12|13|df=yes}}<ref>{{cite web
 |url          = https://github.com/SELinuxProject/selinux/releases/tag/3.6
 |title        = SELinux userspace release 3.6
 |publisher    = SELinux Project
 |date         = 2023-12-14
 |access-date  = 2024-03-16
 |archive-date = 4 March 2024
 |archive-url  = https://web.archive.org/web/20240304021728/https://github.com/SELinuxProject/selinux/releases/tag/3.6
 |url-status   = live
}}</ref>
| latest preview version = 
| latest preview date = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} -->
| programming language = [[C (programming language)|C]]
| operating system = [[Linux]]
| platform = 
| size = 
| language = 
| language count = <!-- DO NOT include this parameter unless you know what it does -->
| language footnote = 
| genre = Security, [[Linux Security Modules]] (LSM)
| license = [[GNU GPL]]
| website = {{URL|https://selinuxproject.org}}, {{URL|1=https://web.archive.org/web/20201022103915/https://www.nsa.gov/what-we-do/research/selinux/|2=https://www.nsa.gov/what-we-do/research/selinux/}}
| standard = 
| AsOf = 
}}

'''Security-Enhanced Linux''' ('''SELinux''') is a [[Linux kernel]] [[Linux Security Modules|security module]] that provides a mechanism for supporting [[access control]] security policies, including [[mandatory access control]]s (MAC).

SELinux is a set of kernel modifications and user-space tools that have been added to various [[Linux distribution]]s. Its [[software architecture|architecture]] strives to separate enforcement of security decisions from the security policy, and streamlines the amount of software involved with security policy enforcement.<ref>{{cite web |url=https://www.nsa.gov/what-we-do/research/selinux/faqs.shtml |title=SELinux Frequently Asked Questions (FAQ) - NSA/CSS |publisher=National Security Agency |access-date=2013-02-06 |archive-date=2018-09-18 |archive-url=https://web.archive.org/web/20180918010353/https://www.nsa.gov/what-we-do/research/selinux/faqs.shtml |url-status=dead }}</ref><ref>{{cite web |first1=Peter |last1=Loscocco |first2=Stephen |last2=Smalley |date=February 2001 |title=Integrating Flexible Support for Security Policies into the Linux Operating System |url=https://www.nsa.gov/resources/everyone/digital-media-center/publications/research-papers/assets/files/flexible-support-for-security-policies-into-linux-feb2001-report.pdf |access-date=23 August 2016 |archive-date=18 September 2018 |archive-url=https://web.archive.org/web/20180918010853/https://www.nsa.gov/resources/everyone/digital-media-center/publications/research-papers/assets/files/flexible-support-for-security-policies-into-linux-feb2001-report.pdf |url-status=live }}</ref> The key concepts underlying SELinux can be traced to several earlier projects by the United States National Security Agency (NSA).

==Overview==
The NSA Security-enhanced Linux Team describes NSA SELinux as<ref>{{cite web |archive-url=https://web.archive.org/web/20201022103915/https://www.nsa.gov/what-we-do/research/selinux/|archive-date=2020-10-22|url=https://www.nsa.gov/what-we-do/research/selinux/ |title=Security-Enhanced Linux - NSA/CSS |publisher=National Security Agency |date=2009-01-15 |access-date=2021-04-21}}</ref>

<blockquote>a set of [[patch (computing)|patches]] to the [[Linux 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.</blockquote>

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 [[daemon (computing)|daemons]] to cause harm if faulty or compromised (for example via [[buffer overflow]]s or misconfigurations). This confinement mechanism operates independently of the traditional Linux ([[discretionary access control|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 on [[setuid]]/[[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 control]]s, [[role-based access control]] (RBAC), and [[type enforcement architecture]]. Third-party tools enable one to build a variety of security policies.

==History==
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 Series|Rainbow 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 the [[Linux kernel mainline]] in the 2.6 series of the Linux kernel.

The NSA, the original primary developer of SELinux, released the first version to the [[Open-source software|open source]] development community under the [[GNU GPL]] on December 22, 2000.<ref>Compare {{cite web
 | url        = https://www.nsa.gov/news-features/press-room/press-releases/2001/se-linux.shtml
 | archive-url = https://web.archive.org/web/20180918025937/https://www.nsa.gov/news-features/press-room/press-releases/2001/se-linux.shtml
 | archive-date = 2018-09-18
 | title      = National Security Agency Shares Security Enhancements to Linux
 | date       = 2001-01-02
 | work       = NSA Press Release
 | publisher  = National Security Agency Central Security Service
 | location   = Fort George G. Meade, Maryland
 | access-date = 2021-04-21
 | quote      = 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.}}</ref> The software was merged into the mainline Linux kernel 2.6.0-test3, released on 8 August 2003. Other significant contributors include [[Red Hat]], [[Network Associates]], [[Secure Computing Corporation]], Tresys Technology, and Trusted Computer Solutions. Experimental ports of the [[FLASK]]/TE implementation have been made available via the [[TrustedBSD]] Project for the [[FreeBSD]] and [[Darwin (operating system)|Darwin]] operating systems.

Security-Enhanced Linux implements the [[FLASK|Flux Advanced Security Kernel]] (FLASK). 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 [[multilevel security]]. FLASK, in turn, was based on DTOS, a Mach-derived [[Distributed Trusted Operating System]], as well as on Trusted Mach, a research project from [[Trusted Information Systems]] that had an influence on the design and implementation of DTOS.{{Citation needed|date=September 2023}}

=== Original and external contributors ===

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 as [https://web.archive.org/web/20081018034429/http://www.nsa.gov/selinux/info/contrib.cfm preserved] 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.<ref>{{cite web |title=Contributors to SELinux |url=http://www.nsa.gov/selinux/info/contrib.cfm|archive-url=https://web.archive.org/web/20081018034429/http://www.nsa.gov/selinux/info/contrib.cfm|archive-date=2008-10-18}}</ref>

{{columns-list|colwidth=20em|
* [[National Security Agency|The National Security Agency]] (NSA)
* [[Network Associates Laboratories]] (NAI Labs)
* [[Mitre Corporation|The MITRE Corporation]]
* [[Secure Computing Corporation]] (SCC)
* Matt Anderson
* Ryan Bergauer
* Bastian Blank
* Thomas Bleher
* Joshua Brindle
* [[Russell Coker]]
* John Dennis
* Janak Desai
* Ulrich Drepper
* Lorenzo Hernandez Garcia-Hierro
* Darrel Goeddel
* Carsten Grohmann
* Steve Grubb
* Ivan Gyurdiev
* Serge Hallyn
* Chad Hanson
* Joerg Hoh
* Trent Jaeger
* Dustin Kirkland
* Kaigai Kohei
* Paul Krumviede
* Joy Latten
* Tom London
* Karl MacMillan
* Brian May
* Frank Mayer
* Todd Miller
* Roland McGrath
* Paul Moore
* James Morris
* Yuichi Nakamura
* Greg Norris
* Eric Paris
* Chris PeBenito
* [[Red Hat]]
* Petre Rodan
* Shaun Savage
* Chad Sellers
* Rogelio Serrano Jr.
* Justin Smith
* Manoj Srivastava
* Tresys Technology
* Michael Thompson
* Trusted Computer Solutions
* Tom Vogt
* Reino Wallin
* Dan Walsh
* Colin Walters
* Mark Westerman
* David A. Wheeler
* Venkat Yekkirala
* Catherine Zhang
}}

==Users, policies and security contexts==
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 command <code>runcon</code> 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, <code>bin_t</code> (all files in the folder /bin) or <code>postgresql_port_t</code> (PostgreSQL port, 5432). The SELinux context for a remote file system can be specified explicitly at mount time.

SELinux adds the <code>-Z</code> switch to the shell commands <code>ls</code>, <code>ps</code>, 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. The <code>audit2allow</code> tool can be used later to produce additional rules that extend the policy to allow all legitimate activities of the application being confined.

=={{Anchor|AVC}}Features==
SELinux features include:
* Clean separation of policy from enforcement
* Well-defined policy interfaces
* Support for applications querying the policy and enforcing access control (for example, [[cron]]d running jobs in the correct context)
* Independence of specific policies and policy languages
* Independence of specific security-label formats and contents
* Individual labels and controls for kernel objects and services
* Support for policy changes
* Separate measures for protecting system integrity (domain-type) and data confidentiality ([[multilevel security]])
* Flexible policy
* Controls over process initialization and inheritance, and program execution
* Controls over file systems, directories, files, and open [[file descriptor]]s
* Controls over sockets, messages, and network interfaces
* Controls over the use of "capabilities"
* Cached information on access-decisions via the ''Access Vector Cache'' (AVC)<ref>{{cite book
 | author     = Fedora Documentation Project
 | title      = Fedora 13 Security-Enhanced Linux User Guide
 | url        = https://books.google.com/books?id=feDeO4IglRkC
 | access-date = 2012-02-22
 | year       = 2010
 | publisher  = Fultus Corporation
 | isbn       = 978-1-59682-215-3
 | page       = 18
 | quote      = 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.}}</ref>
* [[Whitelisting|Default-deny]] policy (anything not explicitly specified in the policy is disallowed)<ref>{{cite web |title=SELinux/Quick introduction - Gentoo Wiki |url=https://wiki.gentoo.org/wiki/SELinux/Quick_introduction#SELinux_policy |website=wiki.gentoo.org}}</ref><ref>{{cite web |title=Getting Started with SELinux |url=https://www.linode.com/docs/security/getting-started-with-selinux/ |website=Linode Guides & Tutorials |date=18 March 2020 |language=en |access-date=8 August 2019 |archive-date=8 August 2019 |archive-url=https://web.archive.org/web/20190808110700/https://www.linode.com/docs/security/getting-started-with-selinux/ |url-status=live }}</ref><ref>{{cite web |title=NB Overview - SELinux Wiki |url=https://selinuxproject.org/page/NB_Overview |website=selinuxproject.org |access-date=8 August 2019 |archive-date=8 August 2019 |archive-url=https://web.archive.org/web/20190808110700/https://selinuxproject.org/page/NB_Overview |url-status=live }}</ref>

==Adoption==
[[File:SELinux sestatus screenshot.png|thumb|upright=1.4|<code>sestatus</code> showing status of SELinux in a system (openSUSE Tumbleweed)]]
SELinux has been implemented in [[Android (operating system)|Android]] since version 4.3.<ref>{{cite web | title=Security-Enhanced Linux in Android | access-date=2016-01-31 | publisher=Android Open Source Project | url=https://source.android.com/security/selinux/ | archive-date=4 January 2018 | archive-url=https://web.archive.org/web/20180104113527/https://source.android.com/security/selinux/ | url-status=live }}</ref>

Among free community-supported Linux distributions, [[Fedora (operating system)|Fedora]] was one of the earliest adopters, including support for it by default since Fedora Core 2. Other distributions include support for it such as [[Debian]] as of version 9 Stretch release<ref>{{cite web|url=https://wiki.debian.org/SELinux|title=SELinux|work=debian.org|access-date=23 August 2016|archive-date=13 August 2020|archive-url=https://web.archive.org/web/20200813103319/https://wiki.debian.org/SELinux|url-status=live}}</ref> and [[Ubuntu (operating system)|Ubuntu]] as of 8.04 Hardy Heron.<ref>{{cite web|url=https://ubuntu-tutorials.com/2008/03/18/how-to-install-selinux-on-ubuntu-804-hardy-heron/|title=How To Install SELinux on Ubuntu 8.04 "Hardy Heron"|work=Ubuntu Tutorials|access-date=23 August 2016|archive-date=5 July 2017|archive-url=https://web.archive.org/web/20170705102909/https://ubuntu-tutorials.com/2008/03/18/how-to-install-selinux-on-ubuntu-804-hardy-heron/|url-status=live}}</ref> As of version 11.1, [[SUSE Linux|openSUSE]] contains SELinux "basic enablement".<ref>{{cite web |url=https://news.opensuse.org/2008/08/20/opensuse-to-add-selinux-basic-enablement-in-111/ |title=openSUSE News |date=20 August 2008 |access-date=23 August 2016 |archive-date=28 September 2020 |archive-url=https://web.archive.org/web/20200928155140/https://news.opensuse.org/2008/08/20/opensuse-to-add-selinux-basic-enablement-in-111/ |url-status=live }}</ref> [[SUSE Linux Enterprise]] (SLE) 11 features SELinux as a "technology preview".<ref>{{cite web |url=https://www.novell.com/linux/releasenotes/x86_64/SUSE-SLED/11/#02 |title=Release Notes for SUSE Linux Enterprise Desktop 11 |publisher=[[Novell]] |access-date=2013-02-06 |archive-date=13 March 2016 |archive-url=https://web.archive.org/web/20160313095523/http://www.novell.com/linux/releasenotes/x86_64/SUSE-SLED/11/#02 |url-status=live }}</ref>

SELinux is popular in systems based on [[Linux containers]], such as [[Container Linux by CoreOS|CoreOS Container Linux]] and rkt.<ref>{{cite web|url=https://coreos.com/os/docs/latest/selinux.html|title=SELinux on CoreOS|work=CoreOS Docs|access-date=15 December 2016|archive-date=26 September 2018|archive-url=https://web.archive.org/web/20180926032756/https://coreos.com/os/docs/latest/selinux.html|url-status=live}}</ref> 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 of [[Red Hat Enterprise Linux]] (RHEL) version 4 and all future releases. This presence is also reflected in corresponding versions of derived systems such as [[CentOS]], [[Scientific Linux]], [[AlmaLinux]] and [[Rocky 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 introduced [[multilevel security]] (MLS) policy for servers only. Fedora Linux 10 introduced a minimum policy, designed for certain platforms such as low-memory devices and [[Virtual machine|virtual machines]].<ref>{{Cite web |title=SELinux/Policies - Fedora Project Wiki |url=https://fedoraproject.org/wiki/SELinux/Policies |access-date=2025-02-14 |website=[[Fedora Linux|Fedora Project]] Wiki |archive-date=11 February 2025 |archive-url=https://web.archive.org/web/20250211201338/https://fedoraproject.org/wiki/SELinux/Policies |url-status=live }}</ref>

openSUSE Tumbleweed transitioned from [[AppArmor]] to SELinux for new installation since 11 February 2025, upcoming SLE/openSUSE Leap 16 will be shipped with SELinux by default as well.<ref>{{Cite web |last=Gompa |first=Neal |date=2025-02-13 |title=Re: Announcement: SELinux as default MAC system on new Tumbleweed installations - openSUSE Factory |url=https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/3JUSAOAXUWDXG4BSU3CEKY4Z3QUMI2US/ |access-date=2025-02-14 |website=openSUSE Mailing Lists |language=en |archive-date=18 February 2025 |archive-url=https://web.archive.org/web/20250218131724/https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/3JUSAOAXUWDXG4BSU3CEKY4Z3QUMI2US/ |url-status=live }}</ref> openSUSE/SLE adopted RHEL/Fedora policies for its SELinux implementation although with some differences.<ref>{{Cite web |title=Portal:SELinux/Differences to fedora policy - openSUSE Wiki |url=https://en.opensuse.org/Portal:SELinux/Differences_to_fedora_policy |access-date=2025-02-15 |website=[[openSUSE]] Wiki}}</ref> 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.<ref>{{Cite web |last=DeMaio |first=Douglas |date=2025-02-13 |title=Tumbleweed Adopts SELinux as Default |url=https://news.opensuse.org/2025/02/13/tw-plans-to-adopt-selinux-as-default/ |access-date=2025-02-13 |website=openSUSE News |language=en}}</ref>

==Use case scenarios==
SELinux can potentially control which activities a system allows each user, process, and daemon, with very precise specifications. It is used to confine [[Daemon (computer software)|daemons]] 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:<ref>{{cite web |url=https://fedoraproject.org/wiki/SELinux/Commands |title=SELinux/Commands - FedoraProject |access-date=2015-11-25 |archive-date=24 October 2020 |archive-url=https://web.archive.org/web/20201024024509/https://fedoraproject.org/wiki/SELinux/Commands |url-status=live }}</ref>
<code>chcon</code>,<ref>{{cite web |url=http://linuxcommand.org/man_pages/chcon1.html |archive-url=https://web.archive.org/web/20041024211853/http://linuxcommand.org/man_pages/chcon1.html |url-status=dead |archive-date=2004-10-24 |title=chcon |publisher=Linuxcommand.org |access-date=2013-02-06 }}</ref>
<code>restorecon</code>,<ref>{{cite web |url=http://linux.die.net/man/8/restorecon |title=restorecon(8) - Linux man page |publisher=Linux.die.net |access-date=2013-02-06 |archive-date=27 February 2021 |archive-url=https://web.archive.org/web/20210227145344/https://linux.die.net/man/8/restorecon |url-status=live }}</ref>
<code>restorecond</code>,<ref>{{cite web |url=http://linux.die.net/man/8/restorecond |title=restorecond(8) - Linux man page |publisher=Linux.die.net |access-date=2013-02-06 |archive-date=27 August 2017 |archive-url=https://web.archive.org/web/20170827014845/https://linux.die.net/man/8/restorecond |url-status=live }}</ref>
<code>runcon</code>,<ref>{{cite web |url=http://linux.die.net/man/1/runcon |title=runcon(1) - Linux man page |publisher=Linux.die.net |access-date=2013-02-06 |archive-date=1 May 2020 |archive-url=https://web.archive.org/web/20200501180729/https://linux.die.net/man/1/runcon |url-status=live }}</ref>
<code>secon</code>,<ref>{{cite web |url=http://linux.die.net/man/1/secon |title=secon(1) - Linux man page |publisher=Linux.die.net |access-date=2013-02-06 |archive-date=26 October 2019 |archive-url=https://web.archive.org/web/20191026154733/https://linux.die.net/man/1/secon |url-status=live }}</ref>
<code>fixfiles</code>,<ref>{{cite web |url=http://linux.die.net/man/8/fixfiles |title=fixfiles(8): fix file SELinux security contexts - Linux man page |publisher=Linux.die.net |access-date=2013-02-06 |archive-date=3 May 2020 |archive-url=https://web.archive.org/web/20200503094354/https://linux.die.net/man/8/fixfiles |url-status=live }}</ref>
<code>setfiles</code>,<ref name="auto">{{cite web |url=http://linux.die.net/man/8/setfiles |title=setfiles(8): set file SELinux security contexts - Linux man page |publisher=Linux.die.net |access-date=2013-02-06 |archive-date=1 May 2020 |archive-url=https://web.archive.org/web/20200501204848/https://linux.die.net/man/8/setfiles |url-status=live }}</ref>
<code>load_policy</code>,<ref>{{cite web |url=http://linux.die.net/man/8/load_policy |title=load_policy(8) - Linux man page |publisher=Linux.die.net |access-date=2013-02-06 |archive-date=26 October 2019 |archive-url=https://web.archive.org/web/20191026143702/https://linux.die.net/man/8/load_policy |url-status=live }}</ref>
<code>booleans</code>,<ref>{{cite web |url=http://linux.die.net/man/8/booleans |title=booleans(8) - Linux man page |publisher=Linux.die.net |access-date=2013-02-06 |archive-date=3 June 2020 |archive-url=https://web.archive.org/web/20200603200637/https://linux.die.net/man/8/booleans |url-status=live }}</ref>
<code>getsebool</code>,<ref>{{cite web |url=http://linux.die.net/man/8/getsebool |title=getsebool(8): SELinux boolean value - Linux man page |publisher=Linux.die.net |access-date=2013-02-06 |archive-date=3 June 2020 |archive-url=https://web.archive.org/web/20200603194859/https://linux.die.net/man/8/getsebool |url-status=live }}</ref>
<code>setsebool</code>,<ref>{{cite web |url=http://linux.die.net/man/8/setsebool |title=setsebool(8): set SELinux boolean value - Linux man page |publisher=Linux.die.net |access-date=2013-02-06 |archive-date=26 October 2019 |archive-url=https://web.archive.org/web/20191026153420/https://linux.die.net/man/8/setsebool |url-status=live }}</ref>
<code>togglesebool</code><ref>{{cite web |url=http://linux.die.net/man/8/togglesebool |title=togglesebool(8) - Linux man page |publisher=Linux.die.net |access-date=2013-02-06 |archive-date=26 August 2020 |archive-url=https://web.archive.org/web/20200826183017/https://linux.die.net/man/8/togglesebool |url-status=live }}</ref>
<code>setenforce</code>,
<code>semodule</code>,
<code>postfix-nochroot</code>,
<code>check-selinux-installation</code>,
<code>semodule_package</code>,
<code>checkmodule</code>,
<code>selinux-config-enforcing</code>,<ref>{{cite web |url=http://manpages.ubuntu.com/manpages/natty/man8/selinux-config-enforcing.8.html |title=Ubuntu Manpage: selinux-config-enforcing - change /etc/selinux/config to set enforcing |publisher=[[Canonical Ltd]] |access-date=2013-02-06 |url-status=dead |archive-url=https://web.archive.org/web/20121220020432/http://manpages.ubuntu.com/manpages/natty/man8/selinux-config-enforcing.8.html |archive-date=2012-12-20 }}</ref>
<code>selinuxenabled</code>,<ref>{{cite web |url=http://manpages.ubuntu.com/manpages/natty/man1/selinuxenabled.1.html |title=Ubuntu Manpage: selinuxenabled - tool to be used within shell scripts to determine if |publisher=[[Canonical Ltd]] |access-date=2013-02-06 |url-status=dead |archive-url=https://web.archive.org/web/20130209033811/http://manpages.ubuntu.com/manpages/natty/man1/selinuxenabled.1.html |archive-date=2013-02-09 }}</ref>
and <code>selinux-policy-upgrade</code><ref>{{cite web |url=http://manpages.ubuntu.com/manpages/natty/man8/selinux-policy-upgrade.8.html |title=Ubuntu Manpage: selinux-policy-upgrade - upgrade the modules in the SE Linux policy |publisher=[[Canonical Ltd]] |access-date=2013-02-06 |url-status=dead |archive-url=https://web.archive.org/web/20120404160143/http://manpages.ubuntu.com/manpages/natty/man8/selinux-policy-upgrade.8.html |archive-date=2012-04-04 }}</ref>

===Examples===
To put SELinux into enforcing mode:
:<code>setenforce 1</code>

To query the SELinux status:
:<code>getenforce</code>

==Comparison with AppArmor==
SELinux represents one of several possible approaches to the problem of restricting the actions that installed software can take. Another popular alternative is called [[AppArmor]] and is available on [[SUSE Linux Enterprise Server]] (SLES), [[openSUSE]], and [[List of Linux distributions#Debian-based|Debian-based]] platforms. AppArmor was developed as a component to the now-defunct [[Immunix|Immunix 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 for [[Discretionary Access Control|DAC]] up to the mandatory access control level.

There are several key differences:
* One important difference is that AppArmor 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.
** As a result, AppArmor can be said not to be a [[type enforcement]] system, as files are not assigned a type; instead, they are merely referenced in a configuration file.
* SELinux and AppArmor also differ significantly in how they are administered and how they integrate into the system.<ref>{{cite web |url= https://www.suse.com/documentation/sles11/book_security/data/sect1_chapter_book_security.html |publisher= SUSE |series= Security Guide |work= SELinux |title= SELinux backgrounds |access-date= 8 June 2016 |archive-date= 1 July 2016 |archive-url= https://web.archive.org/web/20160701143049/https://www.suse.com/documentation/sles11/book_security/data/sect1_chapter_book_security.html |url-status= live }}</ref>
* Since it endeavors to recreate traditional DAC controls with MAC-level enforcement, AppArmor's set of operations is also considerably smaller than those available under most SELinux implementations. For example, AppArmor's set of operations consist of: read, write, append, execute, lock, and link.<ref>{{cite web | url=http://manpages.ubuntu.com/manpages/hardy/man5/apparmor.d.5.html | title=apparmor.d - syntax of security profiles for AppArmor | url-status=dead | archive-url=https://web.archive.org/web/20131017094320/http://manpages.ubuntu.com/manpages/hardy/man5/apparmor.d.5.html | archive-date=2013-10-17 }}</ref> Most SELinux implementations will support numbers of operations orders of magnitude more than that. For example, SELinux will usually support those same permissions, but also includes controls for mknod, binding to network sockets, implicit use of POSIX capabilities, loading and unloading kernel modules, various means of accessing shared memory, etc.
* There are no controls in AppArmor for categorically bounding POSIX capabilities. Since the current implementation of capabilities contains no notion of a subject for the operation (only the actor and the operation) it is usually the job of the MAC layer to prevent privileged operations on files outside the actor's enforced realm of control (i.e. "Sandbox"). AppArmor can prevent its own policy from being altered, and prevent file systems from being mounted/unmounted, but does nothing to prevent users from stepping outside their approved realms of control.
** For example, it may be deemed beneficial for help desk employees to change ownership or permissions on certain files even if they don't own them (for example, on a departmental file share). The administrator does not want to give the user(s) root access on the box so they give them <code>CAP_FOWNER</code> or <code>CAP_DAC_OVERRIDE</code>. 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|date=April 2017}}
* There is no notion of multilevel security with AppArmor, thus there is no hard [[Bell–LaPadula model|BLP]] or [[Biba Model|Biba]] enforcement available.{{Citation needed|date=April 2017}}.
* AppArmor configuration is done using solely regular flat files. SELinux (by default in most implementations) uses a combination of flat files (used by administrators and developers to write human readable policy before it's compiled) and extended attributes.
* SELinux supports the concept of a "remote policy server" (configurable via /etc/selinux/semanage.conf) as an alternative source for policy configuration. Central management of AppArmor is usually complicated considerably since administrators must decide between configuration deployment tools being run as root (to allow policy updates) or configured manually on each server.

==Similar systems and enhancements==
{{See also|Samsung Knox}}

Isolation of processes can also be accomplished by mechanisms such as [[Operating system-level virtualization|virtualization]]; the [[OLPC]] project, for example, in its first implementation<ref>{{cite web|url=http://wiki.laptop.org/go/Rainbow|title=Rainbow|work=laptop.org|access-date=2 March 2009|archive-date=25 December 2020|archive-url=https://web.archive.org/web/20201225051029/http://wiki.laptop.org/go/Rainbow|url-status=live}}</ref> [[Sandbox (computer security)|sandboxed]] individual applications in lightweight [[Vserver]]s. Also, the [[NSA]] has adopted some of the SELinux concepts in Security-Enhanced [[Android (operating system)|Android]].<ref>{{cite web |title=SELinux Related Work |work=NSA.gov |url=https://www.nsa.gov/what-we-do/research/selinux/related-work/ |access-date=2016-08-23 |archive-date=2018-02-20 |archive-url=https://web.archive.org/web/20180220212206/https://www.nsa.gov/what-we-do/research/selinux/related-work/ |url-status=dead }}</ref>

[[General Dynamics]] builds and distributes PitBull Trusted Operating System,<ref>{{cite web|url=https://gdmissionsystems.com/products/platform-security/pitbull-trusted-operating-system|title=PitBull Trusted Operating System|author=General Dynamics}}</ref> a [[multilevel security]] (MLS) enhancement for [[Red Hat Enterprise Linux]].

Multi-Category Security (MCS) is an enhancement to SELinux for [[Red 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 by [[multilevel security]] (MLS).<ref>{{cite web|url=https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/sec-mcs-ov|title=49.4. Multi-Category Security (MCS)|author=Red Hat, Inc.}}</ref>

==See also==
{{Portal|Linux}}
* {{annotated link|AppArmor}}
* {{annotated link|Astra Linux}}
* {{annotated link|Red Star OS}}
* {{annotated link|RSBAC|Rule Set Based Access Control (RSBAC)}}
* {{annotated link|Simplified Mandatory Access Control Kernel}}
* {{annotated link|Solaris Trusted Extensions}}
* {{annotated link|TOMOYO Linux|Tomoyo}}
* {{annotated link|TrustedBSD}}
* {{annotated link|Unix security}}
* {{annotated link|Qubes OS}}

==References==
{{Reflist|30em}}

==External links==
* {{Official website|https://selinuxproject.org/}}
* [https://web.archive.org/web/20081018040612/https://www.nsa.gov/selinux/ Security-Enhanced Linux] at the [[National Security Agency]] in the [[Internet Archive]]
* {{Github|SELinuxProject/selinux|SELinux}}
* {{cite web |url=https://opensource.com/business/13/11/selinux-policy-guide |title=Visual how-to guide for SELinux policy enforcement |date=13 November 2013 |first=Daniel J |last=Walsh |publisher=Opensource.com}}

{{Linux kernel}}
{{Linux}}

{{Authority control}}

[[Category:Linux kernel features]]
[[Category:Linux security software]]
[[Category:National Security Agency]]
[[Category:Red Hat software]]
[[Category:Unix file system technology]]
[[Category:Free software programmed in C]]