| As explained in previous chapters, the SELinux security model is based primarily on a mechanism called type enforcement (TE). Type enforcement assigns processes to domains and restricts the operations each domain is permitted to perform. The SELinux policy, which can be customized by a system administrator, specifies the available domains and the operations that processes within them are authorized to perform. Chapter 7 explains the SELinux type-enforcement model in detail. SELinux also includes a second security model, called role-based access control (RBAC). Role-based access control works alongside type enforcement: intended operations are prohibited unless they're explicitly authorized by both type enforcement and role-based access control. Of course, intended operations must also satisfy any requirements imposed by ordinary Linux discretionary access control mechanisms, such as file permissions. Role-based access control works fairly simply and has three parts . First, each user is authorized for a set of roles. A user cannot enter a role other than one for which the user is authorized. Second, transitions between roles are authorized. A process can transition to a new role only if transitions between its current role and the new role are authorized. Finally, each role is authorized for a set of domains. Any attempt to enter a nonauthorized role or domain is prohibited by the SELinux security engine. Let's consider some concrete examples. Users are assigned roles by the user statement. For instance, the following statement assigns the roles staff_r and sysadm_r to the user bill , permitting the user to enter either role: user bill roles { staff_r sysadm_r };
Transitions between roles are governed by allow statements. For instance, the following allow statement authorizes processes running in the staff_r role to transition to the sysadm_r role: allow staff_r sysadm_r;
Roles are authorized to enter domains by the role statement. For instance, the following statement authorizes the role sysadm_r to enter the ifconfig_t domain: role sysadm_r types ifconfig_t;
A domain can include multiple role statements, each authorizing one or more roles to enter the domain. Unless a role statement authorizes a particular role to enter a domain, processes running in that role cannot enter the domain. Both type enforcement and role-based access control work by inspecting security contexts. Recall that SELinux assigns a security context to each process, as well as to each instance of other objects, such as files. A security context includes three elements: -
A user -
A role -
A type (domain) Thus, at any time, the security context of a process indicates its user identity and role identity, the characteristics considered by role-based access control. A process can change its user or role identity, but only if the current SELinux policy enables the specific transition. For instance, SELinux policies typically permit changing from the staff_r role to the sysadm_r role, but prohibit other roles (such as user_r ) from changing to sysadm_r . Similarly, SELinux policies restrict access to domains, allowing only processes running in specified roles to enter them. For instance, the ifconfig_t domain is authorized to perform various operations that concern network interfaces, which ordinary users should not generally be allowed to perform. Thus, entry to the domain is restricted to processes running in the sysadm_r role, which includes only users designated as system administrators. Role-based access control governs processes rather than files or other objects. So the security contexts of files and other objects are simplified. Although these security contexts contain the three elements common to all security contexts, the role associated with objects other than processes is object_r , which is basically a mere placeholder. The statements that express the SELinux role-based access control policy provide more elaborate options than shown in the preceding examples. To fully explain them, the following section introduces a visual representation of syntax: the railroad diagram. | 