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. The key concepts underlying SELinux can be traced to several earlier projects by the United States National Security Agency (NSA).
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.
# ls -Z total 8 drwxrwx---. 8 robkalmeijer users unconfined_u:object_r:user_home_t:s0 126 Nov 2 15:31 images drwxrwx---. 7 robkalmeijer users unconfined_u:object_r:user_home_t:s0 4096 Jan 19 23:59 pdf drwxrwx---. 11 robkalmeijer users unconfined_u:object_r:user_home_t:s0 4096 Jan 13 13:11 software drwxrwx---. 3 root users unconfined_u:object_r:user_home_t:s0 23 Aug 25 2024 video
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.