RoleRules

From SELinux Wiki
Revision as of 15:43, 29 November 2009 by RichardHaines (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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:

  1. The role allow rule has the same keyword as the allow AV rule.
  2. 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.
  3. 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:

Monolithic Policy
Base Policy
Module Policy
Yes
Yes
Yes
Conditional Policy (if) Statement
optional Statement
require Statement
No
Yes
No


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:

Monolithic Policy
Base Policy
Module Policy
Yes
Yes
Yes
Conditional Policy (if) Statement
optional Statement
require Statement
No
Yes
No


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:

  1. There is another dominance rule for MLS (see the MLS dominance Statement).
  2. The role dominance rule is not used by the Reference Policy as the policy manages role dominance using the constrain Statement.
  3. 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:

Monolithic Policy
Base Policy
Module Policy
Yes
Yes
Yes
Conditional Policy (if) Statement
optional Statement
require Statement
No
Yes
No


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 };}