As previously mentioned, on most operating systems, files, directories, sockets, devices, and so on, are called objects, and processes, such as a user running a command, the Firefox application, and the Apache HTTP Server, are called subjects. SELinux provides flexible MAC that supports a variety of different security models. In Fedora 10, SELinux provides a combination of Role-Based Access Control (RBAC), Type Enforcement® (TE), and optionally, Multi-Level Security (MLS). Subjects and objects are labeled with an SELinux context that contains additional information, such as an SELinux user, role, type, and, optionally, a level. When running SELinux, all of this information is used to make access control decisions.
The following is an example of the labels containing security-relevant information that are used on processes, Linux users, and files, on Linux operating systems that run SELinux. This information is called the SELinux context, and is viewed using the ls -Z command:
$ ls -Z file1 -rwxrw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1
SELinux contexts follow the SELinux user:role:type:level syntax:
The SELinux user identity is an identity known to the policy that is authorized for a specific set of roles and for a specific MLS range. Each Linux user is mapped to an SELinux user via SELinux policy. This allows Linux users to inherit the restrictions on SELinux users. The mapped SELinux user identity is used in the SELinux context for processes in that session in order to bound what roles and levels they can enter. Run the /usr/sbin/semanage login -l command to view a list of mappings between SELinux and Linux user accounts:
Login Name SELinux User MLS/MCS Range __default__ unconfined_u s0-s0:c0.c1023 root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023
Output may differ from system to system. The Login Name column lists Linux users, and the the SELinux User column lists which SELinux user is mapped to which Linux user. For processes, the SELinux user limits which roles and levels are accessible. The last column, MLS/MCS Range, is the level used by Multi-Level Security (MLS) and Multi-Category Security (MCS). Levels are discussed briefly later.
Part of SELinux is the Role-Based Access Control (RBAC) security model. The role is an attribute of RBAC. SELinux users are authorized for roles, and roles are authorized for domains. The role serves as an intermediary between domains and SELinux users. The roles that can be entered determine which domains can be entered - ultimately, this controls which object types can be accessed. This helps reduce vulnerability to privilege escalation attacks.
The type is an attribute of Type Enforcement. The type defines a domain for processes, and a type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it.
The level is an attribute of MLS and Multi-Category Security (MCS). An MLS range is a pair of levels, written as lowlevel-highlevel if the levels differ, or lowlevel if the levels are identical (s0-s0 is the same as s0). Each level is a sensitivity-category pair, with categories being optional. If there are categories, the level is written as sensitivity:category-set. If there are no categories, it is written as sensitivity. If the category set is a contiguous series, it can be abbreviated. For example, c0.c3 is the same as c0,c1,c2,c3. The /etc/selinux/targeted/setrans.conf file maps levels (s0:c0) to human-readable form (CompanyConfidential). Do not allow end-users to edit setrans.conf. It is recommended that changes to setrans.conf be made using /usr/sbin/semanage. Refer to the semanage(8) manual page for further information. In Fedora 10, targeted policy enforces MCS, and in MCS, there is only one sensitivity, s0. MCS in Fedora 10 supports 1024 different categories: c0 through to c1023. s0-s0:c0.c1023 is sensitivity s0, and authorized for all categories.
MLS enforces the Bell-LaPadula Mandatory Access Model, and is used in Labeled Security Protection Profile (LSPP) environments. To use MLS restrictions, install the selinux-policy-mls package, and configure MLS to be the default SELinux policy. The MLS policy shipped with Fedora omits many program domains that were not part of the evaluated configuration, and therefore, MLS on a desktop workstation is unusable (no support for the X Window System); however, an MLS policy from the upstream SELinux Reference Policy can be built that includes all program domains.
A process in one domain transitions to another domain by executing an application that has the entrypoint type for the new domain. The entrypoint permission is used in SELinux policy, and controls which applications can be used to enter a domain. The following example demonstrates a domain transition:
A users wants to change their password. To change their password, they run the /usr/bin/passwd application. The /usr/bin/passwd file is labeled with the passwd_exec_t type:
$ ls -Z /usr/bin/passwd -rwsr-xr-x root root system_u:object_r:passwd_exec_t:s0 /usr/bin/passwd
The passwd application needs to access the /etc/shadow file, which is labeled with the shadow_t type:
$ ls -Z /etc/shadow -r-------- root root system_u:object_r:shadow_t:s0 /etc/shadow
An SELinux policy rule states that processes running in the passwd_t domain are allowed to read and write to files that are labeled with the shadow_t type. Only files and their back up copies that are required for a password change, such as /etc/gshadow, /etc/gshadow- and /etc/shadow, are labeled with the shadow_t type.
An SELinux policy rule states that the passwd_t domain has entrypoint permission to the passwd_exec_t type.
When a user runs the /usr/bin/passwd application, the user's shell process transitions to the passwd_t domain. With SELinux, since the default action is to deny, and a rule exists that allows (among other things) applications running in the passwd_t domain to access files labeled with the shadow_t type, the passwd application is allowed to access /etc/shadow, and update the user's password.
This example is not exhaustive, and is used as a basic example to explain domain transition. Although there is an actual rule that allows subjects running in the passwd_t domain to access objects labeled with the shadow_t file type, other SELinux policy rules must be met before the subject can transition to a new domain. In this example, Type Enforcement ensures:
The passwd_t domain can only be entered by executing an application labeled with the passwd_exec_t type; can only execute from authorized shared libraries, such as the lib_t type; and can not execute any other applications.
Only authorized domains, such as passwd_t, can write to files labeled with the shadow_t type. Even if other processes are running with superuser privileges, those processes can not write to files labeled with the shadow_t type, as they are not running in the passwd_t domain.
Only authorized domains can transition to the passwd_t domain. For example, the sendmail processes running in the sendmail_t domain does not have a legitimate reason to run /usr/bin/passwd; therefore, it can never transition to the passwd_t domain.
Processes running in the passwd_t domain can only read and write authorized types, such as files labeled with the etc_t or shadow_t types. This prevents the passwd application from being tricked into reading or writing arbitrary files.