Security-Enhanced Linux (SELinux) is a Linux feature that provides the mechanism for supporting access control security policies, including United States Department of Defense-style mandatory access controls, through the use of Linux Security Modules (LSM) in the Linux kernel. It is not a Linux distribution, but rather a set of kernel modifications and user-space tools that can be added to various Linux distributions. Its architecture strives to separate enforcement of security decisions from the security policy itself and streamlines the volume of software charged with security policy enforcement.The key concepts underlying SELinux can be traced to several earlier projects by the United States National Security Agency.
It has been integrated into the mainline Linux kernel since version 2.6, on 8 August 2003.
SELinux is a security enhancement to Linux which allows users and administrators more control over access control.
Access can be constrained on such variables as which users and applications can access which resources. These resources may take the form of files. Standard Linux access controls, such as file modes (-rwxr-xr-x) are modifiable by the user and the applications which the user runs. Conversely, SELinux access controls are determined by a policy loaded on the system which may not be changed by careless users or misbehaving applications.
SELinux also adds finer granularity to access controls. Instead of only being able to specify who can read, write or execute a file, for example, SELinux lets you specify who can unlink, append only, move a file and so on. SELinux allows you to specify access to many resources other than files as well, such as network resources and interprocess communication (IPC).
SELinux has three basic modes of operation, of which Enforcing is set as the installation default mode. There is, however, an additional qualifier of targeted or mls which control how pervasive SELinux rules are applied, with targeted being the less stringent level.
Enforcing: The default mode which will enable and enforce the SELinux security policy on the system, denying access and logging actions
Permissive: In Permissive mode, SELinux is enabled but will not enforce the security policy, only warn and log actions. Permissive mode is useful for troubleshooting SELinux issues
Disabled: SELinux is turned off
The SELinux mode can be viewed and changed by using the SELinux Management GUI tool available on the Administration menu or from the command line by running 'system-config-selinux' (the SELinux Management GUI tool is part of the policycoreutils-gui package and is not installed by default).
Users who prefer the command line may use the 'sestatus' command to view the current SELinux status:
# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted
The 'setenforce' command may be used to switch between Enforcing and Permissive modes on the fly but note that these changes do not persist through a system reboot.
To make changes persistent through a system reboot, edit the SELINUX= line in /etc/selinux/config for either 'enforcing', 'permissive', or 'disabled'. For example, SELINUX=permissive.
SELinux has 3 forms of access control:
Type Enforcement (TE): Type Enforcement is the primary mechanism of access control used in the targeted policy
Role-Based Access Control (RBAC): Based around SELinux users (not necessarily the same as the Linux user), but not used in the default targeted policy
Multi-Level Security (MLS): Not commonly used and often hidden in the default targeted policy.
All processes and files have an SELinux security context. Lets see these in action by looking at the SELinux security context of our Apache homepage, index.html:
$ ls -Z /var/www/html/index.html -rw-r--r-- username username system_u:object_r:httpsd_sys_content_t /var/www/html/index.html
In addition to the standard file permissions and ownership, we can see the SELinux security context fields: system_u:object_r:httpsd_sys_content_t.
This is based upon user:role:type:mls. In our example above, user:role:type fields are displayed and mls is hidden. Within the default targeted policy, type is the important field used to implement Type Enforcement, in this case httpsd_sys_content_t.
Now consider the SELinux security context of the Apache web server process, httpsd:
$ ps axZ | grep httpsd system_u:system_r:httpsd_t 3234 ? Ss 0:00 /usr/sbin/httpsd
Here we see the from the type field that Apache is running under the httpsd_t type domain.
Finally, lets look at the SELinux security context of a file in our home directory:
$ ls -Z /home/username/myfile.txt -rw-r--r-- username username user_u:object_r:user_home_t /home/username/myfile.txt
where we see the type is user_home_t, the default type for files in a user's home directory.
Access is only allowed between similar types, so Apache running as httpsd_t can read /var/www/html/index.html of type httpsd_sys_content_t. Because Apache runs in the httpsd_t domain and does not have the userid:username, it can not access /home/username/myfile.txt even though this file is world readable because /home/username/myfile.txt SELinux security context is not of type httpsd_t. If Apache were to be exploited, assuming for the sake of this example that the root account right needed to effect a SELinux relabelling into another context were not obtained, it would not be able to start any process not in the httpsd_t domain (which prevents escalation of privileges) or access any file not in an httpsd_t related domain.