2.7. TE Rules - Types

SELinux uses types in various ways. After they are declared, they can be used to make rules for the transition decision process, type changing process, and access vector decisions and assertions.


Defining the type transitions does not enable them. By default, access is denied until specifically allowed.

Domains are types applied to processes, identified by the type having the domain attribute. The same type is used for the process itself and the associated /proc file. Typically, you see the domain used as the source context for system operations, that is, the domain is the doer. A domain can be a target context, such as when init is sending process signals to a daemon.

With every SELinux transaction involving at least one domain, the number and kind of domains is central to the complexity of the security policy. More domains means finer security control, with a matching increase in configuration and maintenance difficulties.

Type Declaration

This syntax defines how types are declared. A type must be declared before rules can be written about it. The targeted daemons have their top-level domain declared through the macro daemon_domain(), which is discussed in Section 3.4 Common Macros in the Targeted Policy.

## Syntax of a type declaration

type <typename> [aliases] [attributes];

## Examples

type httpd_config_t, file_type, sysadmfile;
# httpd_config_t is a system administration file

type http_port_t, port_type, reserved_port_type;
# httpd_port_t is a reserved port, that is, number less than 1024

type httpd_php_exec_t, file_type, sysadmfile, exec_type;
# httpd_php_exec_t is a sysadmin file that is an entry point 
# executable
Type Transitions

A type transition results in a new process running in a new domain different from the executing process, or a new object being labeled with a type different from the source doing the labeling.

The rules define what domain and file type transitions occur by default. The domain transition default can be overridden if the process explicitly requests a particular context. File transition default is actually inherit-from-parent, that is, the new file receives its context from the parent directory unless an explicit transition rule makes it inherit-from-creator. For example, the directory ~/ has a type of user_home_dir_t, and policy specifies that files created in a directory with that type are labeled with user_home_t.

Transitions are defined through macros that combine the type_transition rule with a set of allow rules. The allow rules are macros with variables that support common transitioning needs. For more information about macros, refer to Section 2.9 Policy Macros.

## General syntax of a transition

type_transition <source_type(s)> <target_type(s)> : \
  <class(es)> <new_type>

# Note that all excepting the <new_type> can be
# multiple types and classes, surrounded by brackets { }

## Domain transition syntax

type_transition <current_domain> <type_of_program> : \
  process <new_domain>

# note that the object class is fixed to the process attribute

## Domain transition examples

type_transition httpd_t httpd_sys_script_exec_t:process \

# When the httpd daemon running in the domain httpd_t executes
# a program of the type httpd_sys_script_exec_t, such as a CGI
# script, the new process is given the domain of
# httpd_sys_script_t

type_transition initrc_t squid_exec_t:process squid_t;

# When init exec()s a program of the type squid_exec_t, the new
# process is transitioned to the squid_t domain

## New object labeling syntax

type_transition <creating_domain> <parent_object_type> : \
  <class(es)> <new_type>

# Note that multiple classes are allowed using the
# { } brackets

## New object labeling example

type_transition named_t var_run_t:sock_file named_var_run_t;

# When a process in the domain named_t creates a socket file
# in a directory of the type var_run_t, the socket file is
# given the type named_var_run_t.  The directory with the
# type var_run_t is defined in the policy as /var/run/.
# This rule is only found in this format in policy.conf,
# and it is derived from the following rule in 
# $SELINUX_SRC/domain/programs/named.te:

file_type_auto_trans(named_t, var_run_t, named_var_run_t, \

# This rule evokes the file_type_auto_trans macro from
# $SELINUX_SRC/macros/core_macros.te, ultimately feeding the 4 
# variables in to the macro file_type_trans($1,$2,$3,$4)

Type Changes

This kind of transition is not used in the targeted policy in Red Hat Enterprise Linux 4. Type changes are used by trusted applications to change the labels of objects, such as login relabeling the tty for a user session. For more information about type changes, refer to the sources found in Chapter 9 References.