![]() | |
![]() SELinux administrator GUI in Arch Linux | |
Original author(s) | NSA and Red Hat |
---|---|
Developer(s) | Red Hat |
Initial release | December 22, 2000 [1] |
Stable release | 3.6 / 13 December 2023 [2] |
Repository | |
Written in | C |
Operating system | Linux |
Type | Security, Linux Security Modules (LSM) |
License | GNU GPL |
Website | selinuxproject |
Security-Enhanced Linux (SELinux) is a Linux kernel security module that provides a mechanism for supporting access control security policies, including mandatory access controls (MAC).
SELinux is a set of kernel modifications and user-space tools that have been added to various Linux distributions. Its architecture 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 of 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.
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). 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 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 controls, role-based access control (RBAC), and type 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 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.
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 development community under the GNU 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 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 systems.
Security-Enhanced Linux implements the 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 ]
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 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. [7]
Linus Torvalds, the creator of the Linux kernel, joked during a LinuxCon keynote on 18 September 2013 that the National Security Agency, the creators of SELinux, wanted a backdoor in the kernel. [8] However, later, Linus's father revealed that the NSA had actually asked for the installation of backdoors in Linux. [9]
When my oldest son [Linus Torvalds] was asked the same question: “Has he been approached by the NSA about backdoors?” he said “No”, but at the same time he nodded. Then he was sort of in the legal free. He had given the right answer, [but] everybody understood that the NSA had approached him.
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 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.
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) or postgresql_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 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. 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 audit2allow
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 systemSELinux has been implemented in Android since version 4.3. [16]
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 as Debian as of version 9 Stretch release [17] and Ubuntu as of 8.04 Hardy Heron. [18] As of version 11.1, openSUSE contains SELinux "basic enablement". [19] SUSE Linux Enterprise 11 features SELinux as a "technology preview". [20]
SELinux is popular in systems based on linux containers, such as CoreOS Container Linux and rkt. [21] 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.
SELinux can potentially control which activities a system allows each user, process, and daemon, with very precise specifications. It is used to confine 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: [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] and selinux-policy-upgrade
[37]
To put SELinux into enforcing mode:
setenforce 1
To query the SELinux status:
getenforce
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 Debian-based platforms. AppArmor was developed as a component to the now-defunct 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 DAC up to the mandatory access control level.
There are several key differences:
CAP_FOWNER
or CAP_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 as virtualization; the OLPC project, for example, in its first implementation [40] sandboxed individual applications in lightweight Vservers. Also, the NSA has adopted some of the SELinux concepts in Security-Enhanced Android. [41]
General Dynamics builds and distributes PitBull Trusted Operating System, [42] 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). [43]
GNU GRUB is a boot loader package from the GNU Project. GRUB is the reference implementation of the Free Software Foundation's Multiboot Specification, which provides a user the choice to boot one of multiple operating systems installed on a computer or select a specific kernel configuration available on a particular operating system's partitions.
chroot
is an operation on Unix and Unix-like operating systems that changes the apparent root directory for the current running process and its children. A program that is run in such a modified environment cannot name files outside the designated directory tree. The term "chroot" may refer to the chroot(2) system call or the chroot(8) wrapper program. The modified environment is called a chroot jail.
Rule-set-based access control (RSBAC) is an open source access control framework for current Linux kernels, which has been in stable production use since January 2000.
Systrace is a computer security utility which limits an application's access to the system by enforcing access policies for system calls. This can mitigate the effects of buffer overflows and other security vulnerabilities. It was developed by Niels Provos and runs on various Unix-like operating systems.
The Flux Advanced Security Kernel (FLASK) is an operating system security architecture that provides flexible support for security policies. It is a joint venture between the National Security Agency, the University of Utah, and the Secure Computing Corporation project designed to provide a framework for a more secure operating system. Development and implementation started with the Mach microkernel, and has since shifted its focus to the Linux operating system. FLASK is a core framework in security-focused operating systems such as NSA's Security-Enhanced Linux (SELinux), OpenSolaris FMAC and TrustedBSD. This means that SELinux can be thought of as an implementation of FLASK.
In computer security, mandatory access control (MAC) refers to a type of access control by which a secured environment constrains the ability of a subject or initiator to access or modify on an object or target. In the case of operating systems, the subject is a process or thread, while objects are files, directories, TCP/UDP ports, shared memory segments, or IO devices. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, the operating system kernel examines these security attributes, examines the authorization rules in place, and decides whether to grant access. A database management system, in its access control mechanism, can also apply mandatory access control; in this case, the objects are tables, views, procedures, etc.
Multilevel security or multiple levels of security (MLS) is the application of a computer system to process information with incompatible classifications, permit access by users with different security clearances and needs-to-know, and prevent users from obtaining access to information for which they lack authorization. There are two contexts for the use of multilevel security.
udev is a device manager for the Linux kernel. As the successor of devfsd and hotplug, udev primarily manages device nodes in the /dev directory. At the same time, udev also handles all user space events raised when hardware devices are added into the system or removed from it, including firmware loading as required by certain devices.
In computer networking, xinetd is an open-source super-server daemon which runs on many Unix-like systems, and manages Internet-based connectivity.
AppArmor is a Linux kernel security module that allows the system administrator to restrict programs' capabilities with per-program profiles. Profiles can allow capabilities like network access, raw socket access, and the permission to read, write, or execute files on matching paths. AppArmor supplements the traditional Unix discretionary access control (DAC) model by providing mandatory access control (MAC). It has been partially included in the mainline Linux kernel since version 2.6.36 and its development has been supported by Canonical since 2009.
Linux Security Modules (LSM) is a framework allowing the Linux kernel to support without bias a variety of computer security models. LSM is licensed under the terms of the GNU General Public License and is a standard part of the Linux kernel since Linux 2.6. AppArmor, SELinux, Smack, and TOMOYO Linux are the currently approved security modules in the official kernel.
The concept of type enforcement (TE), in the field of information technology, is an access control mechanism for regulating access in computer systems. Implementing TE gives priority to mandatory access control (MAC) over discretionary access control (DAC). Access clearance is first given to a subject accessing objects based on rules defined in an attached security context. A security context in a domain is defined by a domain security policy. In the Linux security module (LSM) in SELinux, the security context is an extended attribute. Type enforcement implementation is a prerequisite for MAC, and a first step before multilevel security (MLS) or its replacement multi categories security (MCS). It is a complement of role-based access control (RBAC).
The XTS-400 is a multilevel secure computer operating system. It is multiuser and multitasking that uses multilevel scheduling in processing data and information. It works in networked environments and supports Gigabit Ethernet and both IPv4 and IPv6.
Tomoyo Linux is a Linux kernel security module which implements mandatory access control (MAC).
In computer security, the Linux Intrusion Detection System (LIDS) was a patch to the Linux kernel and associated administrative tools that enhanced the kernel's security by implementing mandatory access control (MAC). When LIDS was in effect all system network administration operations, chosen file access, any capability use, raw device, memory, and I/O access could be made impossible, even for root. One could define which programs can access specific files. It used and extended the system capabilities bounding set to control the whole system and added some network and filesystem security features to the kernel to enhance the security. One could finely tune the security protections online, hide sensitive processes, receive security alerts through the network, and more. LIDS supported Linux kernel 2.6, 2.4. LIDS was released under the terms of the GNU General Public License (GPL).
Smack is a Linux kernel security module that protects data and process interaction from malicious manipulation using a set of custom mandatory access control (MAC) rules, with simplicity as its main design goal. It has been officially merged since the Linux 2.6.25 release, it was the main access control mechanism for the MeeGo mobile Operating System. It is also used to sandbox HTML5 web applications in the Tizen architecture, in the commercial Wind River Linux solutions for embedded device development, in Philips Digital TV products., and in Intel's Ostro OS for IoT devices.
System Integrity Protection is a security feature of Apple's macOS operating system introduced in OS X El Capitan (2015). It comprises a number of mechanisms that are enforced by the kernel. A centerpiece is the protection of system-owned files and directories against modifications by processes without a specific "entitlement", even when executed by the root user or a user with root privileges (sudo).
Snap is a software packaging and deployment system developed by Canonical for operating systems that use the Linux kernel and the systemd init system. The packages, called snaps, and the tool for using them, snapd, work across a range of Linux distributions and allow upstream software developers to distribute their applications directly to users. Snaps are self-contained applications running in a sandbox with mediated access to the host system. Snap was originally released for cloud applications but was later ported to also work for Internet of Things devices and desktop applications.
Dirty COW is a computer security vulnerability of the Linux kernel that affected all Linux-based operating systems, including Android devices, that used older versions of the Linux kernel created before 2018. It is a local privilege escalation bug that exploits a race condition in the implementation of the copy-on-write mechanism in the kernel's memory-management subsystem. Computers and devices that still use the older kernels remain vulnerable.
Android devices have the ability to run virtual machines or emulate other operating systems. It does this either via desktop virtualization, platform virtualization, or emulation via compatibility layer.
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.