Section 6.1. Role-Based Access Control in SELinux

6.1. Role-Based Access Control in SELinux

Roles and users exist in SELinux as the basis for its RBAC feature. It may be surprising that we have not discussed roles or users in any significant way until this point. The security features of most other mainstream operating systems are mostly centered on granting access to users, either directly or through some form of group or role mechanism. This is not the case in SELinux, where access is not granted directly to users or roles. Instead, as discussed in Chapter 5, "Type Enforcement," access is granted to types via TE allow rules. Roles act as a supporting feature to type enforcement, and together with users provide a means to bind type-based access control with Linux users and the programs they are allowed to run. RBAC in SELinux further constrains type enforcement by defining the relationship between domain types and users to control Linux users' privileges and access permissions. RBAC does not allow access. As always in SELinux, allowed access is the providence of type enforcement.

Warning

The fact that Linux and SELinux have distinct user identifiers (that are sometimes related) can be confusing. To help avoid this confusion, we write "Linux user" when meaning the user account as defined in /etc/passwd. Anytime we discuss "user" or "user identifier" without a qualifier, we mean the user identifier in security contexts as defined in the SELinux policy.

6.1.1. Overview of RBAC in SELinux

As stated, in SELinux, RBAC features build upon and support the TE features. We grant privileges to a user indirectly by associating domain types with one or more roles. The RBAC policy statements do not grant access. Instead, RBAC further constrains the TE policy by controlling the associations of domain types, roles, and users in a security context. In this way, the domain transitions available to a user's domain type are restricted based on the user's role, ultimately restricting the total privileges of the user.

To illustrate, consider the example from Chapter 2, "Concepts," which we elaborate further in Figure 6-1. This example illustrates a domain transition from a bash shell process with the domain type user_t to a process running the password program with the domain type passwd_t. Notice that we added the user and role portions of the security contexts for the process security contexts (joe:user_r:user_t and joe:user_r:passwd_t). Let's also assume that the policy includes the necessary TE rules to permit the domain transition (which are not shown).

Figure 6-1. Relationship of users, roles, and types, and the SELinux RBAC statements

This example demonstrates two kinds of RBAC policy statements: a user declaration statement (user) and two role declaration statements (role). These statements create associations between the user, role, and type identifiers in the policy. You will see the full syntax of these statements later in the chapter. For now, understand their effect on domain transitions.

The user statement shown in Figure 6-1 associates the SELinux user joe with the role user_r. This statement tells SELinux that the user joe and the role user_r are allowed to coexists in a security context. Without this statement, the user joe and role user_r process security contexts in Figure 6-1 would be invalid and SELinux would refuse to create them, resulting in a denial of the domain transition attempt.

The two role statements associate the role user_r with the domain types user_t and passwd_t. Like the user statement, the role statements are required for the process security contexts to be valid. In particular, without the role statement associating the type passwd_t, this domain transition would fail even though the TE policy allows it. If we did not want the user_r role to run the password program, we could simply remove this role statement and the security context would never be created by the kernel, even if the TE rules allowed the access.

6.1.2. Managing User Privileges with Roles

As the example in Figure 6-1 illustrates, we do not directly associate domain types with users. Instead, we associate roles with domain types, which are in turn associated with SELinux users. This additional layer of indirection serves two purposes. First, it makes the management of the overall policy less complex. A system may only have three or four roles, but could have many hundreds of users and domain types. Directly associating domain types with users would be difficult to manage. Assigning the domain types to a handful of roles that characterize the privileges of the set of types (for example, ordinary user domain types) and then assigning those roles to users is more manageable.

Roles in SELinux also allow us to limit the access of users based on their current privileges and responsibilities as represented by the active role. For any given process, one role is "active" at a time (that is, the role in the process security context) and, because the domain types are associated with roles, the available domain transitions are limited to those domain types associated with the active role.

Limiting domain transitions to only the currently active role allows a user to be associated with more than one role without gaining the union of the access rights for all the roles. For example, we could associate a user with both a system administration role and a more restrictive ordinary user role, the latter being used for normal interactive, nonadministrative activities. In this scenario, the more restrictive ordinary user role would be active during normal use, preventing access to powerful administrative domain types. The system administrator would "activate" (that is, change via a domain transition) the more privileged administrative role only when necessary to perform system administrative duties. This is similar to, but more fine-grained than, the common best practice for standard Linux of only switching to the root account for system administration and using a normal user account for all other activities.

The key point to remember about roles is that they are only a collection of domain types, which can be conveniently associated with a user. They are not a separate access control mechanism in SELinux.

Tip

A number of utilities such as newrole and a modified su command provide a means by which a user (or user process) changes the current (that is, active) role by creating a new shell process with a different security context via a domain transition (see Chapter 13, "Managing an SELinux System"). (Fedora Core 5 [FC5] removes the ability for su to change roles, instead requiring the use of newrole.) Changing roles is controlled by the associations of users and roles (that is, the user statement) and role allow rules (allow), which we discuss later in the chapter.

Roles Versus User Domain Types

To date, most SELinux policies use roles only in limited ways. This is partly in recognition of the secondary purpose of roles with respect to type enforcement. The typical situation today is that one of the associated domain types for each role is a "user domain type," which is the type that shell processes for users of that role are assigned at initial login. For example, the ordinary, unprivileged user domain type user_t is associated with the role user_r. Likewise, the privileged user's untrusted domain type is staff_t, which is associated with the role staff_r.

These initial user domain types, and all the domain types to which they may transition, are truly what define the roles "user" and "staff." For example, the primary difference between these two "roles" is the ability of the staff role (and hence the staff_t domain type) to transition into the privileged administrator roles and user domain type (sysadm_t, which has an associated sysadm_r role).

One ramification of the practice of having one initial user domain type per role is that we tend to have derived domain types for some programs. For example, to keep downloaded data, including programs, separated by role (reducing the chance of co-opting administrative users), we could run a Web browser in different domain types for each role. To accomplish this goal, we would create different domain transition rules for the associated user domain types (user_t and staff_t). Upon executing the Web browser executable file, each user domain type would transition into separate domain types (that is, user_mozilla_t and staff_mozilla_t), rather than the same type (that is, mozilla_t) as we had with passwd_t. In this way, ordinary users (user_t) and administrative users (staff_t) would have domains for Web browsing protected from each other. We would associate each role only with the appropriate types. (For example, user_mozilla_t would be associated only with user_r.) To complete the separation, we would create separate file types for each Web browser domain and only allow the domains types "write" access to their respective file types. The result would be that the Web browser runs in a different domain depending on the role of the user and the downloaded data is separated based on the role.

6.1.3. Users and Roles in Object Security Contexts

In our password policy example (see Figure 6-1), we did not include the full security context for the file objects shown (that is, the executable file /usr/bin/passwd and the shadow password file /etc/shadow). This absence reflects the relatively low importance of the user and role portion of the security context for objects. Although objects must still have a full security context, the user field at most supports auditing, and roles have no purpose at all. If we examine the objects in Figure 6-1 on our example system, we see the following complete security contexts:

# ls --scontext /usr/bin/passwd /etc/shadow system_u:object_r:shadow_t       /etc/shadow system_u:object_r:passwd_exec_t  /usr/bin/passwd

As you can see, both objects have the special role object_r, which is typically the role for all objects. This role is hard-coded into SELinux, does not need to be declared, and is implicitly allowed for all types. You should never try to declare the role object_r.

The user portion of the security context for objects is usually set to the user portion of the creating process security context. This feature has some potential utility to track which user created the object but in general has no security enforcement purpose (other than possibly constraints, which we discuss in Chapter 9, "Conditional Policies"). In the preceding case, the user for both objects is system_u, which is a special user found in many policies representing system resources and processes.