6.2. Roles and Role StatementsSELinux does not have any built-in roles with the exception of object_r. Roles, like types, are declared in the policy and given meaning through consistent use. Four policy statements relate to roles: role declaration statements, role allow rules, role transition rules, and role dominance statements. 6.2.1. Role Declaration StatementThe role declaration statement (role) declares a role identifier, if it has not already been declared, and associates types with the role. The example in Figure 6-1 contains the following role statements: role user_r types user_t; role user_r types passwd_t; These statements associate the domain types user_t and passwd_t with the role user_r. As you can see, role statements can be repeated for the same role identifier. The first role statement for a given role identifier will declare the role in addition to associating the listed types. All the subsequent role statements associate additional types. Multiple role statements for a single role are commonly used to place the role statements close to the declaration of the types with which they are associated (that is, in the same policy source module). The full syntax for the role declaration statement is provided in the sidebar on page 136.
6.2.2. Role Allow RulesSELinux provides a means to change roles during program execution via the execve() system call. This feature is similar in nature to domain transitions, which result in the domain type changing. Role allow rules (allow) control role changes that can occur on program execution by specifying which roles are allowed to change to other roles. Successful role changes require that a user be authorized for the new role, a corresponding role allow rule permitting the transition from the old role to the new role, and the new role must be authorized for the new domain type. For example, consider the following role allow rule: allow staff_r sysadm_r; This example role allow rule allows a process with the role staff_r to change to the role sysadm_r during a domain transition. This change allows only transition from staff_r to sysadm_r; another role allow rule would be required to transition back from sysadm_r to staff_r. The full syntax for role allow rules is found in the sidebar on page 137. Warning Notice that the role allow rule and the vastly more common TE allow rule discussed in Chapter 5 both have the same keyword (that is, allow). Be careful not to confuse the two rules, whose syntax and semantics differ entirely. In general, when we refer to an "allow rule," we mean the access vector (AV) allow rule discussed in Chapter 5. We endeavor to always write "role allow rule" when we mean the role variety of this keyword.
6.2.3. Role Transition RulesBecause roles can change on program execution in a manner similar to types, we need a means to automate this transition within the policy language. For types, we used the type_transition rule to specify automatic, default type transitions. For roles, we have the role transition rule (role_transition). This rule is similar in purpose and syntax to the type_transition rule except that it specifies a default role change to occur when executing a file. For example, consider this rule: role_transition sysadm_r http_exec_t system_r; This rule states that, unless otherwise requested, when a process with the role sysadm_r executes a file with the type http_exec_t, SELinux should attempt to change the role to system_r. The full syntax for role transition rules is found on page 139. As with type_transition rules, role_transition rules do not allow the access necessary to permit the role change. In this case, role allow rules must also be present for the role change to succeed. Role transition rules are commonly used to change the role of system daemons when directly executed by a system administrator rather than the initialization process (init). If role transition rules were not used in this situation, daemons would have a different role depending on how they were started. Other than this type of situation, we do not expect roles to change implicitly; instead, we expect users to explicitly change their role when necessary using programs designed for that purpose (for example, the newrole command). 6.2.4. Role Dominance StatementA role dominance statement (dominance) declares a role in terms of other roles. We can use this statement to create a hierarchical relationship among roles. In this case, the "dominant role" would automatically inherit all the type associations of the roles it dominates. For example, consider the following statement: dominance { role super_r {role sysadm_r; role secadm_r; } This role dominance statement declares the role super_r, if it has not already been declared, and makes it dominate the roles sysadm_r and secadm_r. The role super_r will have all of the type associations of the roles sysadm_r and secadm_r. If the associations change for either of these "dominated roles," the association will change for super_r, too. Note that any types added to the dominated role after a dominance statement are not inherited by dominant role through the dominance statement. So, in the preceding example, if a type were added to the secadm_r role after the dominance statement, the super_r role would not inherit the new type. The role dominance statement has not yet been widely used in existing policies. The full syntax for the role dominance statement is in the sidebar on page 140.
|