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
Revision as of 13:47, 12 May 2010 (edit) (undo)
RichardHaines (Talk | contribs)

Next diff →
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.+The TE rules define what access control privileges are allowed for processes. There are three types of enforcement rule: [[#type_transition Statement | type_transition]], [[#type_change Statement | type_change]], and [[#type_member Statement | type_member]] 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.+The typebounds statement was added in version 24 of the policy and has a different format that is explained in the [[#typebounds Statement | typebounds Statement]] section.
'''The common format of the Type Enforcement Rule is:''' '''The common format of the Type Enforcement Rule is:'''

Revision as of 13:47, 12 May 2010

Contents

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.

The typebounds statement was added in version 24 of the policy and has a different format that is explained in the typebounds Statement section.

The common format of the Type Enforcement Rule is:

type_rule source_type target_type : class default_type;


Where:

type_rule The applicable type_transition, type_change, or 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 ({}).
default_type A single type identifier that will become the default process type for a domain transition or the type for object transitions.


The statements are valid in:

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


type_transition Statement

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:

# 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 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 (as shown in the
# allow Rule section). 

# A minimum of: add_name, write and search on the var_log_t 
# directory. The actual reference 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
# reference policy has:
#

allow acct_t wtmp_t:file { create open getattr setattr read 
write append rename link unlink ioctl lock };


type_change Statement

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:

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


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 Statement

The typebounds 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:

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
Yes
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 flag an error during policy build.
allow httpd_child_t etc_t : file { read write };
Personal tools