RoleStatements

From SELinux Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 15:31, 29 November 2009 (edit)
RichardHaines (Talk | contribs)
(New page: = Role Statement = == role Statement == The role statement associates a role identifier to one or more types (i.e. authorise the role to access the domain or domains). Where there are mult...)
← Previous diff
Current revision (14:31, 11 December 2014) (edit) (undo)
RichardHaines (Talk | contribs)

 
(3 intermediate revisions not shown.)
Line 1: Line 1:
-= Role Statement =+= Role Statements =
-== role Statement ==+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.
-The role statement 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. +
 +== 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 is:'''+'''The statement definition to declare a role is:'''
<pre> <pre>
role role_id; role role_id;
</pre> </pre>
-'''Or'''+'''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 38: 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 44: Line 46:
|- |-
-|<center>Yes</center>+| <center>'''Yes'''</center>
-|<center>Yes</center>+| <center>'''Yes'''</center>
-|<center>Yes</center>+| <center>'''Yes'''</center>
|- |-
-|<center>'''Conditional Policy (if) Statement'''</center>+| <center>[[ConditionalStatements#if | if Statement]]</center>
-|<center>'''optional Statement'''</center>+| <center>[[PolicyStatements#optional | optional Statement]] </center>
-|<center>'''require Statement'''</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 63: Line 65:
'''Examples:''' '''Examples:'''
<pre> <pre>
-<nowiki># Using the </nowiki>role statement to define standard roles in the+# Declare the roles:
-<nowiki># Reference Policy. Note that there are no domains associated </nowiki>+
-<nowiki># with them yet.</nowiki>+
role system_r; role system_r;
Line 74: Line 74:
role auditadm_r; role auditadm_r;
-<nowiki># Within the policy the roles are then associated to the </nowiki>+# Within the policy the roles are then associated to the
-<nowiki># required domains with this example</nowiki> showing the user_r role +# required types with this example showing the user_r role
-<nowiki># being associated to two domains:</nowiki>+# being associated to two domains:
role user_r types user_t; role user_r types user_t;
role user_r types chfn_t; role user_r types chfn_t;
</pre> </pre>
 +
 +== 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:'''
 +<pre>
 +attribute_role attribute_id;
 +</pre>
 +
 +'''Where:'''
 +
 +{| border="1"
 +| attribute_role
 +| The attribute_role keyword.
 +
 +|-
 +| attribute_id
 +| The attribute identifier.
 +
 +|}
 +
 +
 +'''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>'''Yes'''</center>
 +
 +|}
 +
 +
 +'''Examples:'''
 +<pre>
 +# 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;
 +</pre>
 +
 +== roleattribute ==
 +The roleattribute statement allows the association of previously declared roles to one or more previously declared attribute_roles.
 +
 +'''The statement definition is:'''
 +<pre>
 +roleattribute role_id attribute_id;
 +</pre>
 +
 +'''Where:'''
 +
 +{| border="1"
 +| 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:'''
 +
 +{| 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>
 +
 +|}
 +
 +
 +'''Examples:'''
 +<pre>
 +# 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;
 +</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>
 +|}
 +
 +
 +----
 +<references/>
 +
 +[[Category:Notebook]]

Current revision

Contents

[edit] 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.

[edit] 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:

Monolithic Policy
Base Policy
Module Policy
Yes
Yes
Yes
if Statement
optional Statement
require Statement
No
Yes
Yes


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;

[edit] 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:

Monolithic Policy
Base Policy
Module Policy
Yes
Yes
Yes
if Statement
optional Statement
require Statement
No
Yes
Yes


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;

[edit] 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:

Monolithic Policy
Base Policy
Module Policy
Yes
Yes
Yes
if Statement
optional Statement
require Statement
No
Yes
No


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;

[edit] 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:

Monolithic Policy
Base Policy
Module Policy
Yes
Yes
Yes
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;

[edit] 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:

Monolithic Policy
Base Policy
Module Policy
Yes
Yes
Yes
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;

[edit] 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:

  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.


The statement is valid in:

Monolithic Policy
Base Policy
Module Policy
Yes
Yes
Yes
if Statement
optional Statement
require Statement
No
Yes
No

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
Home
Next



    Personal tools