TypeRules

From SELinux Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 13:38, 12 May 2010 (edit)
RichardHaines (Talk | contribs)

← Previous diff
Current revision (15:53, 18 November 2012) (edit) (undo)
RichardHaines (Talk | contribs)

 
(One intermediate revision not shown.)
Line 1: Line 1:
= Type Enforcement Rules = = Type Enforcement Rules =
-The TE rules define what access control privileges are allowed for processes. There are three types of enforcement rule: type_transition, type_change, and type_member that are explained below.+There are four types of enforcement rule: [[#type_transition Rule | type_transition]], [[#type_change Rule | type_change]], [[#type_member Rule | type_member]] and the [[#typebounds Rule | typebounds]] that are explained below.
-The typebounds statement was added in version 24 of the policy and has a different format that is explained in the typebounds Statement section.+Important note: type enforcement rules only specify the rule and labeling required, it is the <tt>allow</tt> rules that will finally determine if the enforcement rule is actually allowed (or not).
-'''The common format of the Type Enforcement Rule is:'''+== type_transition Rule ==
 +The type_transition rule specifies the labeling and object creation allowed between the source_type and target_type when a Domain Transition is requested. Kernels from 2.6.39 with Policy versions from 25 also support the 'name transition rule' extension.
 + 
 +'''The statement definition is:'''
<pre> <pre>
-type_rule source_type target_type : class default_type;+type_transition source_type target_type : class default_type;
 +</pre>
 + 
 +Policy versions 25 and above also support a 'name transition' rule, however, this is not allowed inside conditionals and currently only supports the <tt>file</tt> class:
 +<pre>
 +type_transition source_type target_type : class default_type object_name;
</pre> </pre>
'''Where:''' '''Where:'''
 +
{|border="1" {|border="1"
-|type_rule+| type_transition
-|The applicable type_transition, type_change, or type_member rule keyword.+| The type_transition rule keyword.
|- |-
-|source_type+| source_type
target_type target_type
-|One or more source / target type or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). +| One or more source / target 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 (-). Entries can be excluded from the list by using the negative operator (-).
|- |-
-|class+| class
-|One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).+| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).
|- |-
-|default_type+| default_type
-|A single type identifier that will become the default process type for a domain transition or the type for object transitions.+| A single type identifier that will become the default process type for a domain transition or the type for object transitions (but see <tt>object_name</tt>).
 + 
 +|-
 +| object_name
 +| For the 'name transition' rule this is matched against the objects name (i.e. the last component of a path). If <tt>object_name</tt> exactly matches the object name, then use <tt>default_type</tt> for the type.
|} |}
-'''The statements are 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>
-|<center>'''Module 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>'''Conditional Policy (if) Statement'''</center>+| <center>'''Conditional Policy (if]) Statement'''</center>
-|<center>'''optional Statement '''</center>+| <center>'''optional Statement'''</center>
-|<center>'''require Statement '''</center>+| <center>'''require Statement'''</center>
|- |-
-|<center>Yes</center>+| <center>Yes</center>
-|<center>Yes</center>+| <center>Yes</center>
-|<center>No</center>+| <center>No</center>
|} |}
-=== type_transition Statement ===+'''Example Domain Transition:'''
-The type_transition statement specifies the labeling and object creation allowed between the source_type and target_type when a Domain Transition is requested.+
- +
- +
-'''Example - Domain Transition:'''+
<pre> <pre>
-<nowiki># Using the </nowiki>type_transition statement to show a domain transition+# Using the type_transition statement to show a domain
-<nowiki># (as the statement has the </nowiki>process object class in the +# transition (as the statement has the process object class
-<nowiki># class). </nowiki>+# in the class).
-<nowiki># The rule states that when a </nowiki>process of type initrc_t executes +# The rule states that when a process of type initrc_t executes
-<nowiki># a file of type </nowiki>acct_exec_t, the process type should be changed+# a file of type acct_exec_t, the process type should be changed
-<nowiki># to </nowiki>acct_t if allowed by the policy (i.e. Transition from the+# to acct_t if allowed by the policy (i.e. Transition from the
-<nowiki># </nowiki>initrc_t domain to the acc_t domain).+# initrc_t domain to the acc_t domain).
type_transition initrc_t acct_exec_t:process acct_t; type_transition initrc_t acct_exec_t:process acct_t;
-<nowiki># Note that to be able to </nowiki>transition to the acc_t domain the +# Note that to be able to transition to the acc_t domain the
-<nowiki># following minimum permissions need to be granted in the policy</nowiki>+# following minimum permissions need to be granted in the policy
-<nowiki># using allow rules (as shown in the </nowiki>allow Rule section).+# using allow rules (as shown in the [#_allow_Rule allow Rule] section).
-<nowiki># File needs to be </nowiki>executable in the initrc_t domain:+
 +# File needs to be executable in the initrc_t domain:
allow initrc_t acct_exec_t:file execute; allow initrc_t acct_exec_t:file execute;
-<nowiki># The executable file needs an </nowiki>entry point into the acct_t domain:+# The executable file needs an entry point into the acct_t
- +# domain:
allow acct_t acct_exec_t:file entrypoint; allow acct_t acct_exec_t:file entrypoint;
-<nowiki># </nowiki>Process needs permission to transition into the acct_t domain:+# Process needs permission to transition into the acct_t domain:
- +
allow initrc_t acct_t:process transition; allow initrc_t acct_t:process transition;
</pre> </pre>
-'''Example - Object Transition:'''+'''Example Object Transition:'''
<pre> <pre>
-<nowiki># Using the </nowiki>type_transition statement to show an object +# Using the type_transition statement to show an object
-<nowiki># transition (as it has other than process in the class).</nowiki>+# transition (as it has other than process in the class).
-<nowiki># The rule states that when a </nowiki>process of type acct_t creates a + 
-<nowiki># file in the directory of type</nowiki> var_log_t, by default it should +# The rule states that when a process of type acct_t creates a
-<nowiki># have the type</nowiki> wtmp_t if allowed by the policy.+# file in the directory of type var_log_t, by default it should
 +# have the type wtmp_t if allowed by the policy.
type_transition acct_t var_log_t:file wtmp_t; type_transition acct_t var_log_t:file wtmp_t;
-<nowiki># Note that to be able to create the new file object with the</nowiki>+# Note that to be able to create the new file object with the
-<nowiki># </nowiki>wtmp_t type, the following minimum permissions need to be +# wtmp_t type, the following minimum permissions need to be
-<nowiki># granted in the policy using allow rules (as shown in the</nowiki>+# granted in the policy using allow rules.
-<nowiki># </nowiki>allow Rule section). +# A minimum of: add_name, write and search on the var_log_t
- +# directory. The actual policy has:
-<nowiki># A minimum of: </nowiki>add_name, write and search on the var_log_t +#
-<nowiki># directory. The actual reference policy has:</nowiki>+
-<nowiki>#</nowiki>+
- +
allow acct_t var_log_t:dir { read getattr lock search ioctl allow acct_t var_log_t:dir { read getattr lock search ioctl
add_name remove_name write }; add_name remove_name write };
-<nowiki># A minimum of: </nowiki>create and write on the wtmp_t file. The actual+# A minimum of: create and write on the wtmp_t file. The actual
-<nowiki># reference policy has:</nowiki>+# policy has:
-<nowiki>#</nowiki>+#
- +
allow acct_t wtmp_t:file { create open getattr setattr read allow acct_t wtmp_t:file { create open getattr setattr read
write append rename link unlink ioctl lock }; write append rename link unlink ioctl lock };
Line 123: Line 129:
-== type_change Statement ==+'''Example Name Transition:'''
-The type_change statement is used to determine any re-labeling of default types for user space SELinux-aware applications that would then manage any required re-labeling via the libselinux API.+
- +
-'''Examples:'''+
<pre> <pre>
-<nowiki># Using the </nowiki>type_change statement to show that when relabeling a +# type_transition to allow using the last path component as
-<nowiki># character file with type</nowiki> sysadm_devpts_t on behalf of +# part of the information in making labeling decisions for
-<nowiki># </nowiki>auditadm_t, the type auditadm_devpts_t should be used:+# new objects. An example rule:
 +#
 +type_transition unconfined_t etc_t : file system_conf_t eric;
-type_change auditadm_t sysadm_devpts_t:chr_file auditadm_devpts_t;+# This rule says if unconfined_t creates a file in a directory
 +# labeled etc_t and the last path component is "eric" (must be
 +# an exact strcmp) it should be labeled system_conf_t.
 +# Note: This rule in not supported in conditionals.
</pre> </pre>
 +
 +== type_change Rule ==
 +The type_change rule is used to define a different label of an object for userspace SELinux-aware applications. These applications would use <tt>'''security_compute_relabel'''(3)</tt> and <tt>type_change</tt> rules in the policy to determine the new context to be applied.
 +
 +'''The statement definition is:'''
<pre> <pre>
-<nowiki># Using the </nowiki>type_change statement to show that when relabeling a +type_change source_type target_type : class change_type;
-<nowiki># character file with any type associated to the attribute </nowiki>+</pre>
-<nowiki># </nowiki>server_ptynode on behalf of staff_t, the type staff_devpts_t + 
-<nowiki># should be used:</nowiki>+ 
 +'''Where:'''
 + 
 +{|border="1"
 +| type_change
 +| The type_change rule keyword.
 + 
 +|-
 +| source_type
 + 
 +target_type
 +| One or more source / target 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 (-).
 + 
 +|-
 +| class
 +| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).
 + 
 +|-
 +| change_type
 +| A single type identifier that will become the new type.
 + 
 +|}
 + 
 + 
 +'''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>'''Conditional Policy (if]) Statement'''</center>
 +| <center>'''optional Statement'''</center>
 +| <center>'''require Statement'''</center>
 + 
 +|-
 +| <center>Yes</center>
 +| <center>Yes</center>
 +| <center>No</center>
 + 
 +|}
 + 
 + 
 +'''Examples:'''
 +<pre>
 +# Using the type_change statement to show that when relabeling a
 +# character file with type sysadm_devpts_t on behalf of
 +# auditadm_t, the type auditadm_devpts_t should be used:
 +type_change auditadm_t sysadm_devpts_t:chr_file auditadm_devpts_t;
 + 
 +# Using the type_change statement to show that when relabeling a
 +# character file with any type associated to the attribute
 +# server_ptynode on behalf of staff_t, the type staff_devpts_t''
 +# should be used:
type_change staff_t server_ptynode:chr_file staff_devpts_t; type_change staff_t server_ptynode:chr_file staff_devpts_t;
</pre> </pre>
-== type_member Statement ==+ 
-The type_member statement determines whether an object can be polyinstantiated. It is used by SELinux-aware applications that would then manage any required polyinstantiation requirements via the libselinux API (see the Polyinstantiation section). Currently only directories are managed by SELinux-aware applications, although the actual statement is not limited to specific object classes.+== type_member Rule ==
 +The type_member rule is used to define a new polyinstantiated label of an object for SELinux-aware applications. These applications would use <tt>'''avc_compute_member'''(3)</tt> or <tt>'''security_compute_member'''(3)</tt> with the <tt>type_member</tt> rules in the policy to determine the context to be applied. The application would then manage any required polyinstantiation.
 + 
 +'''The statement definition is:'''
 +<pre>
 +member_type source_type target_type : class member_type;
 +</pre>
 + 
 + 
 +'''Where:'''
 + 
 +{|border="1"
 +| type_member
 +| The type_member rule keyword.
 + 
 +|-
 +| source_type
 + 
 +target_type
 +| One or more source / target 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 (-).
 + 
 +|-
 +| class
 +| One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).
 + 
 +|-
 +| member_type
 +| A single type identifier that will become the polyinstantiated type.
 + 
 +|}
 + 
 + 
 +'''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>'''Conditional Policy (if) Statement'''</center>
 +| <center>'''optional Statement'''</center>
 +| <center>'''require Statement'''</center>
 + 
 +|-
 +| <center>Yes</center>
 +| <center>Yes</center>
 +| <center>No</center>
 + 
 +|}
'''Example:''' '''Example:'''
<pre> <pre>
-<nowiki># Using the </nowiki>type_member statement to show that if the source +# Using the type_member statement to show that if the source
-<nowiki># type is </nowiki>sysadm_t, and the target type is user_home_dir_t, +# type is sysadm_t, and the target type is user_home_dir_t,
-<nowiki># then use </nowiki>user_home_dir_t as the type on the newly created +# then use user_home_dir_t as the type on the newly created
-<nowiki># directory object.</nowiki>+# directory object.
type_member sysadm_t user_home_dir_t:dir user_home_dir_t; type_member sysadm_t user_home_dir_t:dir user_home_dir_t;
Line 159: Line 289:
- +== typebounds Rule ==
-== typebounds Statement ==+The <tt>typebounds</tt> rule was added in version 24 of the policy. This defines a hierarchical relationship between domains where the bounded domain cannot have more permissions than its bounding domain (the parent). It requires kernel 2.6.28 and above to control the security context associated to threads in multi-threaded applications.
-The <tt>typebounds</tt> statement defines a hierarchical relationship between domains where the bounded domain cannot have any permissions when its bounding domain (the parent) does not have them. It requires kernel 2.6.28 and above to control the security context associated to threads in multi-threaded applications.+
'''The statement definition is:''' '''The statement definition is:'''
<pre> <pre>
-typebounds bounding_domain bounded_domain, [bounded_domain];+typebounds bounding_domain bounded_domain, [bounded_domain] ...;
</pre> </pre>
- 
'''Where:''' '''Where:'''
-{| border="1"+ 
 +{|border="1"
| colspan="2" | typebounds | colspan="2" | typebounds
| The typebounds keyword. | The typebounds keyword.
 +
|- |-
| colspan="2" | bounding_domain | colspan="2" | bounding_domain
| The type identifier of the parent domain. | The type identifier of the parent domain.
 +
|- |-
| bounded_domain | bounded_domain
| colspan="2" | One or more type identifiers of the child domains. | colspan="2" | One or more type identifiers of the child domains.
 +
|} |}
'''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>
-|<center>'''Module 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>'''Conditional Policy (if) Statement'''</center>+| <center>'''Conditional Policy (if) Statement'''</center>
-|<center>'''optional Statement '''</center>+| <center>'''optional Statement'''</center>
-|<center>'''require Statement '''</center>+| <center>'''require Statement'''</center>
|- |-
-|<center>Yes</center>+| <center>No</center>
-|<center>Yes</center>+| <center>Yes</center>
-|<center>No</center>+| <center>No</center>
|} |}
Line 221: Line 354:
# However the child process has been given 'write' access that # However the child process has been given 'write' access that
-# will flag an error during policy build.+# will not be allowed by the kernel SELinux security server.
allow httpd_child_t etc_t : file { read write }; allow httpd_child_t etc_t : file { read write };
</pre> </pre>
 +
 +
 +----
 +<references/>
 +
 +[[Category:Notebook]]

Current revision

Contents

[edit] Type Enforcement Rules

There are four types of enforcement rule: type_transition, type_change, type_member and the typebounds that are explained below.

Important note: type enforcement rules only specify the rule and labeling required, it is the allow rules that will finally determine if the enforcement rule is actually allowed (or not).

[edit] type_transition Rule

The type_transition rule specifies the labeling and object creation allowed between the source_type and target_type when a Domain Transition is requested. Kernels from 2.6.39 with Policy versions from 25 also support the 'name transition rule' extension.

The statement definition is:

type_transition source_type target_type : class default_type;

Policy versions 25 and above also support a 'name transition' rule, however, this is not allowed inside conditionals and currently only supports the file class:

type_transition source_type target_type : class default_type object_name;


Where:

type_transition The type_transition rule keyword.
source_type

target_type

One or more source / target 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 (-).

class One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).
default_type A single type identifier that will become the default process type for a domain transition or the type for object transitions (but see object_name).
object_name For the 'name transition' rule this is matched against the objects name (i.e. the last component of a path). If object_name exactly matches the object name, then use default_type for the type.


The statement is valid in:

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


Example Domain Transition:

# Using the type_transition statement to show a domain
# transition (as the statement has the process object class
# in the class). 

# The rule states that when a process of type initrc_t executes 
# a file of type acct_exec_t, the process type should be changed
# to acct_t if allowed by the policy (i.e. Transition from the
# initrc_t domain to the acc_t domain).

type_transition initrc_t acct_exec_t:process acct_t;

# Note that to be able to transition to the acc_t domain the 
# following minimum permissions need to be granted in the policy
# using allow rules (as shown in the [#_allow_Rule allow Rule] section).

# File needs to be executable in the initrc_t domain:
allow initrc_t acct_exec_t:file execute;

# The executable file needs an entry point into the acct_t
# domain:
allow acct_t acct_exec_t:file entrypoint;

# Process needs permission to transition into the acct_t domain:
allow initrc_t acct_t:process transition;


Example Object Transition:

# Using the type_transition statement to show an object 
# transition (as it has other than process in the class).

# The rule states that when a process of type acct_t creates a 
# file in the directory of type var_log_t, by default it should 
# have the type wtmp_t if allowed by the policy.

type_transition acct_t var_log_t:file wtmp_t;

# Note that to be able to create the new file object with the
# wtmp_t type, the following minimum permissions need to be 
# granted in the policy using allow rules. 
# A minimum of: add_name, write and search on the var_log_t 
# directory. The actual policy has:
#
allow acct_t var_log_t:dir { read getattr lock search ioctl 
add_name remove_name write };

# A minimum of: create and write on the wtmp_t file. The actual
# policy has:
#
allow acct_t wtmp_t:file { create open getattr setattr read 
write append rename link unlink ioctl lock };


Example Name Transition:

# type_transition to allow using the last path component as 
# part of the information in making labeling decisions for 
# new objects. An example rule:
#
type_transition unconfined_t etc_t : file system_conf_t eric;

# This rule says if unconfined_t creates a file in a directory
# labeled etc_t and the last path component is "eric" (must be
# an exact strcmp) it should be labeled system_conf_t. 
# Note: This rule in not supported in conditionals. 


[edit] type_change Rule

The type_change rule is used to define a different label of an object for userspace SELinux-aware applications. These applications would use security_compute_relabel(3) and type_change rules in the policy to determine the new context to be applied.

The statement definition is:

type_change source_type target_type : class change_type;


Where:

type_change The type_change rule keyword.
source_type

target_type

One or more source / target 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 (-).

class One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).
change_type A single type identifier that will become the new type.


The statement is valid in:

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


Examples:

# Using the type_change statement to show that when relabeling a 
# character file with type sysadm_devpts_t on behalf of 
# auditadm_t, the type auditadm_devpts_t should be used:
type_change auditadm_t sysadm_devpts_t:chr_file auditadm_devpts_t;

# Using the type_change statement to show that when relabeling a 
# character file with any type associated to the attribute 
# server_ptynode on behalf of staff_t, the type staff_devpts_t'' 
# should be used:

type_change staff_t server_ptynode:chr_file staff_devpts_t;


[edit] type_member Rule

The type_member rule is used to define a new polyinstantiated label of an object for SELinux-aware applications. These applications would use avc_compute_member(3) or security_compute_member(3) with the type_member rules in the policy to determine the context to be applied. The application would then manage any required polyinstantiation.

The statement definition is:

member_type source_type target_type : class member_type;


Where:

type_member The type_member rule keyword.
source_type

target_type

One or more source / target 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 (-).

class One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).
member_type A single type identifier that will become the polyinstantiated type.


The statement is valid in:

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


Example:

# Using the type_member statement to show that if the source 
# type is sysadm_t, and the target type is user_home_dir_t, 
# then use user_home_dir_t as the type on the newly created 
# directory object.

type_member sysadm_t user_home_dir_t:dir user_home_dir_t;


[edit] typebounds Rule

The typebounds rule was added in version 24 of the policy. This defines a hierarchical relationship between domains where the bounded domain cannot have more permissions than its bounding domain (the parent). It requires kernel 2.6.28 and above to control the security context associated to threads in multi-threaded applications.

The statement definition is:

typebounds bounding_domain bounded_domain, [bounded_domain] ...;

Where:

typebounds The typebounds keyword.
bounding_domain The type identifier of the parent domain.
bounded_domain One or more type identifiers of the child domains.


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 example has been taken from A secure web application platform powered by SELinux.

# The httpd_child_t cannot have file:{write} due to lack of
# permissions on httpd_t which is the parent. It means the 
# child domains will always have equal or less privileges
# than the parent.

# The typebounds statement:
typebounds httpd_t httpd_child_t;

# The parent is allowed file 'getattr' and 'read':
allow httpd_t etc_t : file { getattr read };

# However the child process has been given 'write' access that
# will not be allowed by the kernel SELinux security server.
allow httpd_child_t etc_t : file { read write };



    Personal tools