Difference between revisions of "RoleStatements"
(→Role Statement) |
|||
Line 1: | Line 1: | ||
= Role Statements = | = Role Statements = | ||
− | Policy version 26 introduced two new role statements aimed at replacing the role <tt>dominance</tt> rule by making role relationships easier to understand. These new statements: <tt>attribute_role</tt> and<tt> roleattribute</tt> | + | Policy version 26 introduced two new role statements aimed at replacing the role <tt>dominance</tt> rule by making role relationships easier to understand. These new statements: <tt>attribute_role</tt> and<tt> roleattribute</tt> are defined in this section with examples. |
+ | == role == | ||
+ | The role statement either declares a role identifier or associates a role identifier to one or more types (i.e. authorise the role to access the domain or domains). Where there are multiple role statements declaring the same role, the compiler will associate the additional types with the role. | ||
− | + | '''The statement definition to declare a role is:''' | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | '''The statement definition is:''' | + | |
<pre> | <pre> | ||
role role_id; | role role_id; | ||
</pre> | </pre> | ||
− | ''' | + | '''The statement definition to associate a role to one or more types is:''' |
<pre> | <pre> | ||
role role_id types type_id; | role role_id types type_id; | ||
</pre> | </pre> | ||
− | |||
'''Where:''' | '''Where:''' | ||
− | {|border="1" | + | |
− | |role | + | {| border="1" |
− | |The role keyword. | + | | role |
+ | | The role keyword. | ||
|- | |- | ||
− | |role_id | + | | role_id |
− | |The identifier of the role being declared. The same role identifier can be declared more than once in a policy, in which case the type_id entries will be amalgamated by the compiler. | + | | The identifier of the role being declared. The same role identifier can be declared more than once in a policy, in which case the type_id entries will be amalgamated by the compiler. |
|- | |- | ||
− | |types | + | | types |
− | |The optional types keyword. | + | | The optional types keyword. |
|- | |- | ||
− | |type_id | + | | type_id |
− | |When used with the types keyword, one or more type or attribute identifiers associated with the role_id. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-). | + | | When used with the types keyword, one or more type, <tt>typealias</tt> or attribute identifiers associated with the role_id. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-). |
− | For role statements, only type or attribute identifiers associated to domains have any meaning within SELinux. | + | For role statements, only type, <tt>typealias</tt> or attribute identifiers associated to domains have any meaning within SELinux. |
|} | |} | ||
Line 42: | Line 39: | ||
'''The statement is valid in:''' | '''The statement is valid in:''' | ||
− | {|border="1" | + | |
+ | {| border="1" | ||
|<center>'''Monolithic Policy'''</center> | |<center>'''Monolithic Policy'''</center> | ||
|<center>'''Base Policy'''</center> | |<center>'''Base Policy'''</center> | ||
Line 48: | Line 46: | ||
|- | |- | ||
− | |<center>Yes</center> | + | | <center>'''Yes'''</center> |
− | |<center>Yes</center> | + | | <center>'''Yes'''</center> |
− | |<center>Yes</center> | + | | <center>'''Yes'''</center> |
|- | |- | ||
− | |<center> | + | | <center>[[ConditionalStatements#if | if Statement]]</center> |
− | |<center> | + | | <center>[[PolicyStatements#optional | optional Statement]] </center> |
− | |<center> | + | | <center>[[PolicyStatements#require | require Statement]] </center> |
|- | |- | ||
− | |<center>No</center> | + | | <center>'''No'''</center> |
− | |<center>Yes</center> | + | | <center>'''Yes'''</center> |
− | |<center>Yes</center> | + | | <center>'''Yes'''</center> |
|} | |} | ||
Line 67: | Line 65: | ||
'''Examples:''' | '''Examples:''' | ||
<pre> | <pre> | ||
− | + | # Declare the roles: | |
− | + | ||
− | + | ||
role system_r; | role system_r; | ||
Line 78: | Line 74: | ||
role auditadm_r; | role auditadm_r; | ||
− | + | # Within the policy the roles are then associated to the | |
− | + | # required types with this example showing the user_r role | |
− | + | # being associated to two domains: | |
role user_r types user_t; | role user_r types user_t; | ||
Line 86: | Line 82: | ||
</pre> | </pre> | ||
− | + | == attribute_role == | |
− | + | ||
− | == attribute_role | + | |
The attribute_role statement declares a role attribute identifier that can then be used to refer to a group of roles. | The attribute_role statement declares a role attribute identifier that can then be used to refer to a group of roles. | ||
Line 96: | Line 90: | ||
</pre> | </pre> | ||
+ | '''Where:''' | ||
− | + | {| border="1" | |
− | {|border="1" | + | |
| attribute_role | | attribute_role | ||
| The attribute_role keyword. | | The attribute_role keyword. | ||
Line 110: | Line 104: | ||
'''The statement is valid in:''' | '''The statement is valid in:''' | ||
− | {|border="1" | + | |
− | | <center>'''Monolithic Policy'''</center> | + | {| border="1" |
− | | <center>'''Base Policy'''</center> | + | |<center>'''Monolithic Policy'''</center> |
− | | <center>'''Module Policy'''</center> | + | |<center>'''Base Policy'''</center> |
+ | |<center>'''Module Policy'''</center> | ||
|- | |- | ||
− | | <center>Yes</center> | + | | <center>'''Yes'''</center> |
− | | <center>Yes</center> | + | | <center>'''Yes'''</center> |
− | | <center>Yes</center> | + | | <center>'''Yes'''</center> |
|- | |- | ||
− | | <center> | + | | <center>[[ConditionalStatements#if | if Statement]]</center> |
− | | <center> | + | | <center>[[PolicyStatements#optional | optional Statement]] </center> |
− | | <center> | + | | <center>[[PolicyStatements#require | require Statement]] </center> |
|- | |- | ||
− | | <center>No</center> | + | | <center>'''No'''</center> |
− | | <center>Yes</center> | + | | <center>'''Yes'''</center> |
− | | <center>Yes</center> | + | | <center>'''Yes'''</center> |
|} | |} | ||
Line 143: | Line 138: | ||
</pre> | </pre> | ||
− | + | == roleattribute == | |
− | == roleattribute | + | |
The roleattribute statement allows the association of previously declared roles to one or more previously declared attribute_roles. | The roleattribute statement allows the association of previously declared roles to one or more previously declared attribute_roles. | ||
'''The statement definition is:''' | '''The statement definition is:''' | ||
<pre> | <pre> | ||
− | roleattribute role_id attribute_id | + | roleattribute role_id attribute_id; |
</pre> | </pre> | ||
+ | '''Where:''' | ||
− | + | {| border="1" | |
− | {|border="1" | + | |
| roleattribute | | roleattribute | ||
| The roleattribute keyword. | | The roleattribute keyword. | ||
Line 170: | Line 164: | ||
'''The statement is valid in:''' | '''The statement is valid in:''' | ||
− | {|border="1" | + | |
− | | <center>'''Monolithic Policy'''</center> | + | {| border="1" |
− | | <center>'''Base Policy'''</center> | + | |<center>'''Monolithic Policy'''</center> |
− | | <center>'''Module Policy'''</center> | + | |<center>'''Base Policy'''</center> |
+ | |<center>'''Module Policy'''</center> | ||
|- | |- | ||
− | | <center>Yes</center> | + | | <center>'''Yes'''</center> |
− | | <center>Yes</center> | + | | <center>'''Yes'''</center> |
− | | <center>Yes</center> | + | | <center>'''Yes'''</center> |
|- | |- | ||
− | | <center> | + | | <center>[[ConditionalStatements#if | if Statement]]</center> |
− | | <center> | + | | <center>[[PolicyStatements#optional | optional Statement]] </center> |
− | | <center> | + | | <center>[[PolicyStatements#require | require Statement]] </center> |
|- | |- | ||
− | | <center>No</center> | + | | <center>'''No'''</center> |
− | | <center>Yes</center> | + | | <center>'''Yes'''</center> |
− | | <center>No</center> | + | | <center>'''No'''</center> |
|} | |} | ||
Line 205: | Line 200: | ||
roleattribute service_r role_list_1; | roleattribute service_r role_list_1; | ||
</pre> | </pre> | ||
+ | |||
+ | == allow == | ||
+ | The role allow rule checks whether a request to change roles is allowed, if it is, then there may be a further request for a role_transition so that the process runs with the new role or role set. | ||
+ | |||
+ | Note that the role allow rule has the same keyword as the allow AV rule. | ||
+ | |||
+ | '''The statement definition is:''' | ||
+ | <pre> | ||
+ | allow from_role_id to_role_id; | ||
+ | </pre> | ||
+ | |||
+ | '''Where:''' | ||
+ | |||
+ | {| border="1" | ||
+ | | allow | ||
+ | | The role allow rule keyword. | ||
+ | |||
+ | |- | ||
+ | | from_role_id | ||
+ | | One or more role or <tt>attribute_role</tt> identifiers that identify the current role. Multiple entries consist of a space separated list enclosed in braces ({}). | ||
+ | |||
+ | |- | ||
+ | | to_role_id | ||
+ | | One or more role or <tt>attribute_role</tt> identifiers that identify the new role to be granted on the transition. Multiple entries consist of a space separated list enclosed in braces ({}). | ||
+ | |||
+ | |} | ||
+ | |||
+ | |||
+ | '''The statement is valid in:''' | ||
+ | |||
+ | {| border="1" | ||
+ | |<center>'''Monolithic Policy'''</center> | ||
+ | |<center>'''Base Policy'''</center> | ||
+ | |<center>'''Module Policy'''</center> | ||
+ | |||
+ | |- | ||
+ | | <center>'''Yes'''</center> | ||
+ | | <center>'''Yes'''</center> | ||
+ | | <center>'''Yes'''</center> | ||
+ | |||
+ | |- | ||
+ | | <center>[[ConditionalStatements#if | if Statement]]</center> | ||
+ | | <center>[[PolicyStatements#optional | optional Statement]] </center> | ||
+ | | <center>[[PolicyStatements#require | require Statement]] </center> | ||
+ | |||
+ | |- | ||
+ | | <center>'''No'''</center> | ||
+ | | <center>'''Yes'''</center> | ||
+ | | <center>'''No'''</center> | ||
+ | |||
+ | |} | ||
+ | |||
+ | |||
+ | '''Example:''' | ||
+ | <pre> | ||
+ | # Using the role allow rule to define authorised role | ||
+ | # transitions in the Reference Policy. The current role | ||
+ | # sysadm_r is granted permission to transition to the secadm_r | ||
+ | # role in the MLS policy. | ||
+ | |||
+ | allow sysadm_r secadm_r; | ||
+ | </pre> | ||
+ | |||
+ | == role_transition == | ||
+ | The role_transition rule specifies that a role transition is required, and if allowed, the process will run under the new role. From policy version 25, the class can now be defined. | ||
+ | |||
+ | '''The statement definition is:''' | ||
+ | <pre> | ||
+ | role_transition current_role_id type_id new_role_id; | ||
+ | </pre> | ||
+ | |||
+ | Or from Policy version 25: | ||
+ | <pre> | ||
+ | role_transition current_role_id type_id : class new_role_id; | ||
+ | </pre> | ||
+ | |||
+ | '''Where:''' | ||
+ | |||
+ | {| border="1" | ||
+ | | role_transition | ||
+ | | The role_transition keyword. | ||
+ | |||
+ | |- | ||
+ | | current_role_id | ||
+ | | One or more role or <tt>attribute_role</tt> identifiers that identify the current role. Multiple entries consist of a space separated list enclosed in braces ({}). | ||
+ | |||
+ | |- | ||
+ | | type_id | ||
+ | | One or more type, <tt>typealias</tt> or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-). | ||
+ | |||
+ | |- | ||
+ | | class | ||
+ | | For policy versions >= 25 an object class that applies to the role transition. If omitted defaults to the <tt>process</tt> object class. | ||
+ | |||
+ | |- | ||
+ | | new_role_id | ||
+ | | A single <tt>role</tt> identifier that will become the new role. | ||
+ | |||
+ | |} | ||
+ | |||
+ | |||
+ | '''The statement is valid in:''' | ||
+ | |||
+ | {| border="1" | ||
+ | |<center>'''Monolithic Policy'''</center> | ||
+ | |<center>'''Base Policy'''</center> | ||
+ | |<center>'''Module Policy'''</center> | ||
+ | |||
+ | |- | ||
+ | | <center>'''Yes'''</center> | ||
+ | | <center>'''Yes'''</center> | ||
+ | | <center>'''Yes'''</center> | ||
+ | |||
+ | |- | ||
+ | | <center>[[ConditionalStatements#if | if Statement]]</center> | ||
+ | | <center>[[PolicyStatements#optional | optional Statement]] </center> | ||
+ | | <center>[[PolicyStatements#require | require Statement]] </center> | ||
+ | |||
+ | |- | ||
+ | | <center>'''No'''</center> | ||
+ | | <center>'''Yes'''</center> | ||
+ | | <center>'''No'''</center> | ||
+ | |||
+ | |} | ||
+ | |||
+ | |||
+ | '''Example:''' | ||
+ | <pre> | ||
+ | # This is a role_transition used in the ext_gateway.conf | ||
+ | # loadable module to allow the secure client / server process to | ||
+ | # run under the message_filter_r role. The role needs to be | ||
+ | # declared, allowed to transition from its current role of | ||
+ | # unconfined_r and it then transitions when the process | ||
+ | # transitions via the type_transition statement (not shown). | ||
+ | # Note that the role needs to be associated to a user by either: | ||
+ | # 1) An embedded user statement in the policy. This is not | ||
+ | # recommended as it makes the policy fixed to either | ||
+ | # standard, MCS or MLS. | ||
+ | # 2) Using the semanage(8) command to add the role. This will | ||
+ | # allow the module to be used by MCS/MLS policies as well. | ||
+ | # | ||
+ | |||
+ | # The secure client / server will run in this domain: | ||
+ | type ext_gateway_t; | ||
+ | |||
+ | # The binaries will be labeled: | ||
+ | type secure_services_exec_t; | ||
+ | |||
+ | # Use message_filter_r role and then transition | ||
+ | role message_filter_r types ext_gatway_t; | ||
+ | allow unconfined_r message_filter_r; | ||
+ | role_transition unconfined_r secure_services_exec_t message_filter_r; | ||
+ | </pre> | ||
+ | |||
+ | == dominance == | ||
+ | This rule has been deprecated and therefore should not be used. The role dominance rule allows the dom_role_id to dominate the role_id (consisting of one or more roles). The dominant role will automatically inherit all the type associations of the other roles. | ||
+ | |||
+ | Notes: | ||
+ | |||
+ | # There is another dominance rule for MLS (see the MLS [[MLSStatements#dominance | dominance]] statement). | ||
+ | # The role dominance rule is not used by the Reference Policy as the policy manages role dominance using the [[ConstraintStatements | constrain]] statement. | ||
+ | # Note the usage of braces '{}' and the '<nowiki>;</nowiki>' in the statement. | ||
+ | |||
+ | '''The statement definition is:''' | ||
+ | <pre> | ||
+ | dominance { role dom_role_id { role role_id; } } | ||
+ | </pre> | ||
+ | |||
+ | '''Where:''' | ||
+ | |||
+ | {| border="1" | ||
+ | | dominance | ||
+ | | The dominance keyword. | ||
+ | |||
+ | |- | ||
+ | | role | ||
+ | | The role keyword. | ||
+ | |||
+ | |- | ||
+ | | dom_role_id | ||
+ | | The dominant role identifier. | ||
+ | |||
+ | |- | ||
+ | | role_id | ||
+ | | For the simple case each { role role_id; } pair defines the role_id that will be dominated by the dom_role_id. | ||
+ | |||
+ | |} | ||
+ | |||
+ | |||
+ | '''The statement is valid in:''' | ||
+ | |||
+ | {| border="1" | ||
+ | |<center>'''Monolithic Policy'''</center> | ||
+ | |<center>'''Base Policy'''</center> | ||
+ | |<center>'''Module Policy'''</center> | ||
+ | |||
+ | |- | ||
+ | | <center>'''Yes'''</center> | ||
+ | | <center>'''Yes'''</center> | ||
+ | | <center>'''Yes'''</center> | ||
+ | |||
+ | |- | ||
+ | | <center>[[ConditionalStatements#if | if Statement]]</center> | ||
+ | | <center>[[PolicyStatements#optional | optional Statement]] </center> | ||
+ | | <center>[[PolicyStatements#require | require Statement]] </center> | ||
+ | |||
+ | |- | ||
+ | | <center>'''No'''</center> | ||
+ | | <center>'''Yes'''</center> | ||
+ | | <center>'''No'''</center> | ||
+ | |||
+ | |} | ||
+ | |||
+ | '''Example:''' | ||
+ | <pre> | ||
+ | # This shows the dominance role rule, note however that it | ||
+ | # has been deprecated and should not be used. | ||
+ | |||
+ | dominance { role message_filter_r { role unconfined_r };} | ||
+ | </pre> | ||
+ | |||
+ | |||
+ | {| style="width: 100%;" border="0" | ||
+ | |- | ||
+ | | [[UserStatements | '''Previous''']] | ||
+ | | <center>[[NewUsers | '''Home''']]</center> | ||
+ | | <center>[[TypeStatements | '''Next''']]</center> | ||
+ | |} | ||
Latest revision as of 14:31, 11 December 2014
Contents
Role Statements
Policy version 26 introduced two new role statements aimed at replacing the role dominance rule by making role relationships easier to understand. These new statements: attribute_role and roleattribute are defined in this section with examples.
role
The role statement either declares a role identifier or associates a role identifier to one or more types (i.e. authorise the role to access the domain or domains). Where there are multiple role statements declaring the same role, the compiler will associate the additional types with the role.
The statement definition to declare a role is:
role role_id;
The statement definition to associate a role to one or more types is:
role role_id types type_id;
Where:
role | The role keyword. |
role_id | The identifier of the role being declared. The same role identifier can be declared more than once in a policy, in which case the type_id entries will be amalgamated by the compiler. |
types | The optional types keyword. |
type_id | When used with the types keyword, one or more type, typealias or attribute identifiers associated with the role_id. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).
For role statements, only type, typealias or attribute identifiers associated to domains have any meaning within SELinux. |
The statement is valid in:
|
|
|
|
|
|
|
|
|
Examples:
# Declare the roles: role system_r; role sysadm_r; role staff_r; role user_r; role secadm_r; role auditadm_r; # Within the policy the roles are then associated to the # required types with this example showing the user_r role # being associated to two domains: role user_r types user_t; role user_r types chfn_t;
attribute_role
The attribute_role statement declares a role attribute identifier that can then be used to refer to a group of roles.
The statement definition is:
attribute_role attribute_id;
Where:
attribute_role | The attribute_role keyword. |
attribute_id | The attribute identifier. |
The statement is valid in:
|
|
|
|
|
|
|
|
|
Examples:
# Using the attribute_role statement to declare attributes that # can then refers to a list of roles. Note that there are no # roles associated with them yet. attribute_role role_list_1; attribute_role srole_list_2;
roleattribute
The roleattribute statement allows the association of previously declared roles to one or more previously declared attribute_roles.
The statement definition is:
roleattribute role_id attribute_id;
Where:
roleattribute | The roleattribute keyword. |
role_id | The identifier of a previously declared role. |
attribute_id | One or more previously declared attribute_role identifiers. Multiple entries consist of a comma (,) separated list. |
The statement is valid in:
|
|
|
|
|
|
|
|
|
Examples:
# Using the roleattribute statement to associate a previously # declared role of service_r to a previously declared # role_list_1 attribute_role. attribute_role role_list_1; role service_r; # The association using the roleattribute statement: roleattribute service_r role_list_1;
allow
The role allow rule checks whether a request to change roles is allowed, if it is, then there may be a further request for a role_transition so that the process runs with the new role or role set.
Note that the role allow rule has the same keyword as the allow AV rule.
The statement definition is:
allow from_role_id to_role_id;
Where:
allow | The role allow rule keyword. |
from_role_id | One or more role or attribute_role identifiers that identify the current role. Multiple entries consist of a space separated list enclosed in braces ({}). |
to_role_id | One or more role or attribute_role identifiers that identify the new role to be granted on the transition. Multiple entries consist of a space separated list enclosed in braces ({}). |
The statement is valid in:
|
|
|
|
|
|
|
|
|
Example:
# Using the role allow rule to define authorised role # transitions in the Reference Policy. The current role # sysadm_r is granted permission to transition to the secadm_r # role in the MLS policy. allow sysadm_r secadm_r;
role_transition
The role_transition rule specifies that a role transition is required, and if allowed, the process will run under the new role. From policy version 25, the class can now be defined.
The statement definition is:
role_transition current_role_id type_id new_role_id;
Or from Policy version 25:
role_transition current_role_id type_id : class new_role_id;
Where:
role_transition | The role_transition keyword. |
current_role_id | One or more role or attribute_role identifiers that identify the current role. Multiple entries consist of a space separated list enclosed in braces ({}). |
type_id | One or more type, typealias or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-). |
class | For policy versions >= 25 an object class that applies to the role transition. If omitted defaults to the process object class. |
new_role_id | A single role identifier that will become the new role. |
The statement is valid in:
|
|
|
|
|
|
|
|
|
Example:
# This is a role_transition used in the ext_gateway.conf # loadable module to allow the secure client / server process to # run under the message_filter_r role. The role needs to be # declared, allowed to transition from its current role of # unconfined_r and it then transitions when the process # transitions via the type_transition statement (not shown). # Note that the role needs to be associated to a user by either: # 1) An embedded user statement in the policy. This is not # recommended as it makes the policy fixed to either # standard, MCS or MLS. # 2) Using the semanage(8) command to add the role. This will # allow the module to be used by MCS/MLS policies as well. # # The secure client / server will run in this domain: type ext_gateway_t; # The binaries will be labeled: type secure_services_exec_t; # Use message_filter_r role and then transition role message_filter_r types ext_gatway_t; allow unconfined_r message_filter_r; role_transition unconfined_r secure_services_exec_t message_filter_r;
dominance
This rule has been deprecated and therefore should not be used. The role dominance rule allows the dom_role_id to dominate the role_id (consisting of one or more roles). The dominant role will automatically inherit all the type associations of the other roles.
Notes:
- There is another dominance rule for MLS (see the MLS dominance statement).
- The role dominance rule is not used by the Reference Policy as the policy manages role dominance using the constrain statement.
- Note the usage of braces '{}' and the ';' in the statement.
The statement definition is:
dominance { role dom_role_id { role role_id; } }
Where:
dominance | The dominance keyword. |
role | The role keyword. |
dom_role_id | The dominant role identifier. |
role_id | For the simple case each { role role_id; } pair defines the role_id that will be dominated by the dom_role_id. |
The statement is valid in:
|
|
|
|
|
|
|
|
|
Example:
# This shows the dominance role rule, note however that it # has been deprecated and should not be used. dominance { role message_filter_r { role unconfined_r };}
Previous | |
|