Section 2.3. The Role of Roles

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 ( assuming the type enforcement rules allow the transition), thereby defining the limits of the role. Take our password program example in Figure 2-5. Although according to the type enforcement rules, the password program can be executed by the user_t domain type to enter the new passwd_t domain, Joe's role must also be allowed to be associated with the new domain type for the transition to occur. To illustrate , we extend the password program example in Figure 2-6.

Figure 2-6. Roles in domain transitions

We have added the role portion ( user_r ) of the security contexts for the processes depicted. We also added a new rule, specifically the role statement :

role user_r type passwd_t;

The role statement declares role identifiers and associates types with the declared role. The previous statement declares the role user_r (if it has not already been declared in the policy) and associates the type passwd_t with the role. What this association means is that the passwd_t type is allowed to coexist in a security context with the role user_r . Without this role statement, the new context joe:user_r:passwd_t could not be created, and the execve () system call would fail, even though the TE policy allows Joe's type ( user_t ) all the necessary access.

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 classified government applications, traditional multilevel security (MLS) MAC coupled with type enforcement is valuable . In recognition of these situations, SELinux has always had some form of MLS capability included. The MLS features are optional and generally the less important of the two MAC mechanisms in SELinux. For the vast majority of security applications, including many if not most classified data applications, type enforcement is the best-suited mechanism for enhanced security. Nonetheless, the addition of MLS enhances security for some applications.

The basic concept of MLS was introduced in Chapter 1, "Background;" actual implementations of MLS are more involved. The security level used by MLS systems is a combination of a hierarchical sensitivity and a set (including the null set) of nonhierarchical categories . These sensitivities and categories are used to reflect real information confidentiality or user clearances. In most SELinux policies, the sensitivities ( s0 , s1 , ...) and categories ( c0 , c1 , ...) are given generic names, leaving it to userspace programs and libraries to assign user-meaningful names . (For example, s0 might be associated with UNCLASSIFIED and s1 with SECRET.)

To support MLS, the security context is extended to include security levels as such these:

user:role:type:sensitivity[:category,...][-sensitivity[:category,...]]

Notice that the MLS security context must have at least one security level (which is composed of a single sensitivity and zero or more categories), but can include two security levels. These two security levels are called low (or current for processes) and high (or clearance for processes), respectively. If the high security level is missing, it is considered to be the same value as the low (the most common situation). In practice, the low and high security levels are usually the same for most objects and processes. A range of levels is typically used for processes that are considered trusted subjects (that is, a process trusted with the ability to downgrade information) or multilevel objects such as directories that might contain objects of differing security levels. For purposes of this overview, assume that all processes and objects have a single security level.

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 dominance relationship . Unlike equality where a level is either higher than, equal to, or lower than another level, in a dominance relationship, there is a fourth state called incomparable (also known as noncomparable ; see the definition of incomp in the following list). What causes security levels to be related via dominance rather than equality are the categories, which have no hierarchical relationship to one another. As a result, the four dominance operators that can relate two MLS security levels are as follows :


dom:	( dominates ) SL1 dom SL2 if the sensitivity of SL1 is higher or equal to the sensitivity of SL2, and the categories of SL1 are a superset of the categories of SL2.
domby:	( dominated by ) SL1 domby SL2 if the sensitivity of SL1 is lower than or equal to the sensitivity of SL2, and the categories of SL1 are a subset of the categories of SL2.
eq:	( equals ) SL1 eq SL2 if the sensitivity of SL1 and SL2 are equal, and the categories of SL1 and SL2 are the same set .
incomp:	( incomparable or noncomparable ) SL1 incomp SL2 if the categories of SL1 and SL2 cannot be compared (that is, neither is a subset of the other).

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.

Buy on amazon.com >>

Mayer F., MacMillan K., Caplan D.

<< Previous page

Table of contents

Next page >>