Access decisions are one of the two basic kinds of decisions made by the SELinux security server. Transition decisions—which are sometimes called labeling decisions—are the second.
Since every object has a security context, newly created objects must be labeled with some security context. A transition decision decides what security context is chosen. Transition decisions come up in two common contexts:
The new process may run in the same domain as its parent or in another authorized domain. If the process runs in another domain, a domain transition is said to have occurred.
The new file (or file-like object, such as a directory) may be labeled with the security context of the directory containing it or with another authorized domain. If the file’s security context pertains to a domain other than that of the directory that contains it, a file-type transition—or, more simply, a type transition—is said to have occurred.
In SELinux, the terms domain and type are synonymous. The term domain is more often used in reference to processes, while type is more often used in reference to passive objects such as files.
Let’s first consider
process
creation. Given permission, a running
process—called
a parent process—may invoke the
exec
syscall, creating a new process—called
a child process—
by executing a specified
program file. Generally, the child process runs in the same SELinux
domain as the parent process and receives the same SID and security
context. However, some programs are defined in the SELinux policy as
entry points to domains. When such a program is
executed, the child process is given a new security context having
another domain. The process is said to have
transitioned to a new domain.
Domain transitions occur only subject to policy restrictions. A process cannot transition to a domain other than one for which it has been authorized.
Processes can also transition to new domains by using the SELinux application programming interface (API). Programs that need to make special transitions (for example, the login and SSH daemons) have been modified to use the special SELinux APIs that accomplish them. In order that they not compromise system security, such programs permit their programmed transitions only under carefully regulated conditions.
Figure 2-5 illustrates process creation with and
without a domain transition. In the left half of the figure, a user
runs the vi
editor in a domain named
vi_t
. When the user executes the
ls
command from within vi
,
both vi
and the ls
command
run in the
vi_t
domain; no
transition occurs. In the right half of the figure, the Init process
is running in the
initrc_t
domain. When
Init starts the SSH service daemon, a domain transition occurs, so
that the SSH service daemon runs in its own domain, the
sshd_t
domain.
Recall that access decisions are generally based on the domain of the subject and object, along with the class of the object and the requested action. When a process transitions to a new domain, its permissions become those associated with the new domain. Thus, the permissions of processes can be specified with high granularity and flexibility.
Transition decisions related to file creation work similarly. By default, a newly created file or file-like object receives the security context of the directory that contains it. However, an SELinux policy rule can specify that files created by a process running in a particular domain are specially labeled. Figure 2-6 illustrates the default situation and a situation influenced by a policy rule.
In the upper half of Figure 2-6, the
sort
utility runs in the
sort_t
domain. The utility creates a temporary
file, /tmp/sorted_result
, which receives the
same file type as that of its parent directory,
/tmp
; namely, tmp_t
. This
demonstrates automatic inheritance of file type. In the lower half of
the figure, an SELinux policy rule causes explicit assignment of a
special file type. There, the /tmp/log.tmp
file
created by the Syslog process receives the file type
syslog_tmp_t
rather than the
file type of its
parent directory.