TypeRules

From SELinux Wiki
Revision as of 15:53, 18 November 2012 by RichardHaines (Talk | contribs)

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

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).

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. 


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;


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;


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