Configuring Security Policies

The specific policy that is enforced by the kernel is dictated by security policy configuration files. These text-based configuration files allow the security server implementation to support many security policies. They account for a significant part of security policy flexibility possible with SELinux. Once a security policy specification is completed, it is straightforward to customize that policy to meet the specific needs of different installations. It is possible to maintain different security policies that address completely different security objectives with just one base system.

The configuration files are written using a simple language developed for the security server. The configuration is checked and compiled into a binary representation that is loaded into the security server at boot time. It may also be reloaded at runtime as controlled by the policy.

The TE configuration file defines an extensible set of types. Using the allow statement, allowable permissions between pairs of types are specified for each object class.

allow type_1 type_2:class { perm_1 ... perm_n };

The TE configuration file defines automatic transitions between types when programs of certain types are executed. Such transitions ensure that system processes and certain programs are placed into their own separate domains automatically when executed. It also defines default labels for files created by programs of certain types in certain types of directories to ensure that files are created with the right types. Both are done using the type_transition statement.

type_transition type_1 type_2: file 
     default_file_type;

type_transition type_1 type_2: process 
     default_process_domain;

The RBAC configuration file defines an extensible set of roles. Each process has an associated role. The configuration file specifies the set of types that may be entered by processes executing in a given role. The role statement is used to define the roles.

role rolename types { type_1 ... type_n };

As users execute programs, transitions to other roles may, according to the policy configuration, automatically occur to support changes in privilege. A role transition rule specifies the default role of a transformed process based on its prior role and the type of the program executable. If no rule is specified, then the default role of a process is the same as its role prior to the execve call. The role_transition statement is used to define the roles.

role_transition current_role program_type new_role;

Although the language allows role transitions to occur on program execution, the SELinux configuration never uses this functionality. Instead it uses domain transitions for changes in privileges during a session. Roles are only allowed to change on login or by executing the newrole program which causes a user authentication. Unlike the TE policy, the RBAC policy has no entrypoint controls to control the transition into roles. Care must be taken when granting this capability. Role changes tend to involve significant changes in privileges (e.g user becoming system administrator) whereas domain transitions tend to be finer-grained changes.

The IBAC configuration file defines each user recognized by the system security policy. Each user has a set of roles that may be entered by processes with the user's identity. This is specified with the user statement.

user username roles { role_1 ... role_n };

There are two other configuration files available to further specify a security policy. They are the assert.te and constraints files. The first allows the specification of TE assertions that must hold true for the expressed policy to be valid. The second uses boolean expressions to express restrictions on users or roles. Both are useful tools to construct security policies.

Lastly, the operation of SELinux depends not only on the security policy configuration but also on the labels of objects in the file system. New objects are labeled when they are created. When the object is moved onto persistent storage, a persistent SID (PSID) is stored with that object. The PSID represents a security context, and a mapping between them is stored within the file system. PSIDs are mapped into SIDs when the kernel accesses the object. See [13,17] for a more complete discussion on PSIDS.

When existing file systems are brought into SELinux, labels must be assigned. The file_contexts configuration file specifies security contexts for files based on pathname regular expressions. The setfiles utility program reads this configuration and sets the security contexts on each file accordingly. When setfiles is run, the system stores the proper PSID with each file and updates the security context mapping. In this way, the security policy can depend on the file system labels.