Security-Enhanced Linux - Users, Policies and Security Contexts

Users, Policies and Security Contexts

SELinux users and roles are not related to the actual system users and roles. For every current user or process, SELinux assigns a three string context consisting of a role, user name, 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. Circumstance for when the user is allowed to get 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 configuration.

Files, network ports, and other hardware also have an SELinux context, consisting of a name, role (seldom used), and type. In case of the 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 often consist of explicit permissions; 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, making 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.