A key feature of Type Enforcement (TE) security is the ability to define domain types with which programs run, use that domain type to control access to objects (which are also typed), and strictly control the ability of a process to change its domain type. This last ability is known as domain transition.
Apol supports analysis of an SELinux policy to understand the domain transitions it allows. As with all access in SELinux, the ability to transition from one domain to another is controlled by 'allow' rules in the policy. Below, we describe how apol performs a domain transition analysis.
When discussing domain transition access, there are three different types we must consider:
In SELinux, there are two ways for a domain transition to occur,
on exec()
, and on setcon()
.
The common case is for a domain transition to occur on exec()
.
In SELinux, four types of access (and hence at four rules) must be allowed by the policy for a domain transition to occur. These access types form the criteria used by apol to determine allowed transitions.
The criteria for an allowed domain transition are as
follows. In the examples below, assume user_t
is the source type,
passwd_t
is the target type, and passwd_exec_t
is the file entry
point type.
transition
access for process
object class for the TARGET domain type. For
example, the rule:allow user_t passwd_t : process transition;meets this criterion by allowing the source type (
user_t
) process:
transition
permission to the target type (passwd_t
).execute
access to the FILE ENTRYPOINT type. For example, the rule:allow user_t passwd_exec_t : file { read getattr execute };meets the criterion by allowing the source type (
user_t
) execute
access to the file entrypoint type (passwd_exec_t
).entrypoint
access to the FILE ENTRYPOINT type for file objects. For
example, the rule:allow passwd_t passwd_exec_t : file entrypoint;meets this criterion by allowing the target type (
passwd_t
) file:
entrypoint
access to the file entrypoint type (passwd_exec_t
).type_transition user_t password_exec_t : process passwd_t;meets this criterion by specifying that when
user_t
executes
a program with the passwd_exec_t
type, the default type of the
new process is passwd_t
. This is the most common specifier because
it does not require the programs to be SELinux-aware. Alternatively,
the program can be made SELinux-aware and the program itself may
specify the type of the new process. For example, the statement:allow user_t self : process setexec;allows the source type (
user_t
) to specify the type of new processes
when executing programs. In both the type transition and setexec
cases, the types that the source domain may transition to are
limited by the previous three criterion.In the analysis results, apol will list all the types that meet the above four criteria.
SELinux also supports domain transitions that are requested by SELinux-aware
programs (also known as a dynamic domain transition),
using the setcon()
libselinux function. Two types of access
must be allowed by the policy for a dynamic domain
transition to occur. These access types form the criteria used by apol
to determine allowed transitions.
The criteria for an allowed dynamic domain transition are as
follows. In the examples below, assume souce_t
is the source type
and, target_t
is the target type.
dyntransition
access for process
object class for the TARGET domain type. For
example, the rule:allow source_t target_t : process transition;meets this criterion by allowing the source type (
source_t
) process:
dyntransition
permission to the target type (target_t
).setcurrent
access so it can set its current SELinux context. For example, the rule:allow source_t source_t : process setcurrent;meets the criterion by allowing the source type (
source_t
) setcurrent
access on itself.In the analysis results, apol will list all the types that meet the above two criteria.
Apol supports both forward and reverse domain transition analysis. A forward analysis determines all the TARGET types to which the selected SOURCE types may transition (find child domains/processes). A reverse analysis is the opposite; select a TARGET type and determine all the SOURCE types that may transition to the target type (find parent domains/processes).