Section 6.2. Roles and Role Statements


6.2. Roles and Role Statements

SELinux 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 Statement

The 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.

Role Declaration Statement Syntax

Role declaration statements declare role identifiers and associate types with the role. A type must be associated with a role to coexist in a security context with the role. The special role object_r is predefined and is implicitly associated with all types and used in the security context of all objects. There can be multiple role statements for the same role identifier. The first statement declares the role and associates one or more types; the subsequent statements only associate types. The full syntax for the role statement is as follows:

role role_name [types type_set];


role_name

An identifier for the role. If this is the first role statement for this identifier, the role is declared. The identifier can be any length and can contain ASCII characters, numbers, periods, and underscores (_). A period has a special meaning when used in a role identifier. A period is used to indicate restrictions on the set of types that may be assigned to a role. For example, the set of types for a role called apache.cgi must be a subset of the type set of a role called apache.

type_set

One or more type or attribute identifiers. Multiple identifiers are specified using a space-separated list enclosed in braces ({ })for example, {user_t passwd_t }. Types can be excluded from the list by prepending - to the type name (for example, { exec_type -sbin_t }). If type_set is omitted (along with the types keyword), the role is declared without any type associations.


Role declarations are valid in monolithic policies, base loadable modules, and non-base loadable modules. They are not valid in conditional statements.


6.2.2. Role Allow Rules

SELinux 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.


Role Allow Rule Syntax

Role allow rules authorize role changes on program execution. The full syntax for the role allow rule is as follows:

allow role_set role_set;


role_set

One or more role identifiers. Multiple identifiers are specified using a space-separated list enclosed in braces ({ })for example,

{ staff_r sysadm_r }



Role allow rules are valid in monolithic policies, base loadable modules, and non-base loadable modules. They are not valid in conditional statements.


6.2.3. Role Transition Rules

Because 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 Statement

A 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.

Role Transition Rule Syntax

Role transition rules specify a default role change to occur when executing a file of a given type. Role transition rules do not allow access. Role allow rules must also be present for the role change to succeed. The full syntax for role transition rules is as follows:

role_transition role_set type_set role;


role_set

One or more role identifiers. Multiple identifiers are specified using a space-separated list enclosed in braces ({})for example, { staff_r sysadm_r }.

type_set

One or more type or attribute identifiers. Multiple identifiers are specified using a space-separated list enclosed in braces ({ })for example, { user_t passwd_t }. Types can be excluded from the list by prepending - to the type name (for example, {exec_type -sbin_t }).

role

The new role for the security context after the role transition.


Role transition rules are valid in monolithic policies, base loadable modules, and non-base loadable modules. They are not valid in conditional statements.


Role Dominance Statement Syntax

The role dominance statement specifies a hierarchical relationship among roles. Roles inherit all the type associations of the roles they dominate. The basic syntax of the role dominance statement is as follows:

dominance { role role_name { role_set}  }


role_name

An identifier for the role. The identifier can be any length and can contain ASCII characters, numbers, period, and underscore (_).

role_set

One or more roles specified in the form role role_name;. Multiple roles are specified using a space-separated list (for example, { role staff_r; role sysadm_r; }).


The policy language does support a much more complicated syntax where the role_set can contain embedded dominance relationship definitions that are indicated with braces. For example:

dominance { role a_r { role b_r; role c_r { role d_r; } } }


In this example, the roles would be defined as follows:

d_r

Only its own types

c_r

Its types and those of d_r

b_r

Only its own types

a_r

Its own types and all types in b_r, c_r, and d_r


Role dominance statements are valid in monolithic policies, base loadable modules, and non-base loadable modules. They are not valid in conditional statements.





SELinux by Example(c) Using Security Enhanced Linux
SELinux by Example: Using Security Enhanced Linux
ISBN: 0131963694
EAN: 2147483647
Year: 2007
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net