2.3. The Role of Roles
SELinux also provides a form of
role-based access control
(RBAC). The RBAC feature of SELinux is built upon type enforcement; access control in SELinux is primarily via type enforcement. Roles limit the types to which a process may transition based on the role identifier in the process' security context. In this manner, a policy writer can create a role that is allowed to transition into a set of domain types (
Figure 2-6. Roles in domain transitions
We have added the role portion (
) of the security contexts for the processes depicted. We also added a new rule,
role user_r type passwd_t;
statement declares role identifiers and
A policy writer can define roles that are further constrained and then associate these roles to specific users. For example, imagine that in our policy we also create a role called restricted_user_r , identical to user_r in all regards except that it is not associated with the passwd_t type. Thus, if Joe's role is restricted_user_r instead of user_r , Joe would not be authorized to run the password program even though the TE rules would allow his domain type the access.
Chapter 6, "Roles and Users," discusses in detail the purposes of roles in SELinux and in particular how they are created and associated with users.
2.4. Multilevel Security in SELinux
Type enforcement is far and away the most important
mandatory access control
(MAC) mechanism that SELinux introduces. However, in some situations, primarily for a subset of
The basic concept of MLS was introduced in Chapter 1, "Background;" actual
To support MLS, the security context is extended to include security levels as such these:
Notice that the MLS security context must have at least one security level (which is
The MLS rules for accessing objects are much the same as discussed in Chapter 1, except that security levels are not hierarchical but rather governed by a
Given the domain relationship, a variation of the Bell-La Padula model is implemented in SELinux where a process can "read" an object if its current security level dominates the security level of the object, and "write" an object if its current security level is dominated by the security level of the object (and therefore read and write the object only if the two security levels are equal ).
The MLS constraints in SELinux are in addition to the TE rules. If MLS is enabled, both checks must pass (in addition to standard Linux access control) for access to be granted. Chapter 8, "Multilevel Security," discusses the SELinux optional MLS features.