RoleRules
Role Rules
Role allow Rule
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.
Important Notes:
- The role allow rule has the same keyword as the allow AV rule.
- The role allow rule is used in the Reference Policy sources, however there are no corresponding role_transition rules. This is because the policy expects users to either keep the same role as when they logged onto the system, or use the newrole(1) command to change roles.
- The Reference Policy uses the constrain Statement to manage role relationships.
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 identifiers that identify the current role. Multiple entries consist of a space separated list enclosed in braces ({}). |
to_role_id | One or more 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 Rule
The role_transition rule specifies that a role transition is required, and if allowed, the process will run under the new role.
The statement definition is:
role_transition current_role_id type_id new_role_id;
Where:
role_transition | The role_transition keyword. |
current_role_id | One or more role identifiers that identify the current role. Multiple entries consist of a space separated list enclosed in braces ({}). |
type_id | One or more type 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 (-). Only 'domain' types make sense within the policy. |
new_role_id | The new role to be granted on transition. |
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;
Role dominance Rule
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. More complex rules can be defined but as the statement is depreciated !!!. |
The statement is valid in:
Example:
# This shows the dominance role rule note however that it # has been depreciated and should not be used. dominance { role message_filter_r { role unconfined_r };}