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