This chapter is an overview of the SELinux architecture,
building upon what was discussed in Section 1 What
Is SELinux?. The technical information you learn here helps
you accomplish your goals in an SELinux environment. This chapter
discusses the interaction of SELinux policy, the kernel, and the
rest of the OS. Chapter 2
SELinux Policy Overview provides a more detailed look
into the policy itself.
For a history of SELinux and the Flask architecture, read
Appendix A Brief
Background and History of SELinux.
Flask was developed to work through some of the inherent
problems with a MAC architecture. Traditional MAC is closely
integrated with the multi-level security
(MLS) model. Access decisions in MLS
are based on clearances for subjects and classifications for
objects, with the objective of no read-up, no
write-down . This provides a very static lattice that allows
the system to decide by a subject's security clearance level which
objects can be read and written to. The focus of the MLS
architecture is entirely on maintaining confidentiality.
The inflexible aspect of this kind of MAC is the focus on
confidentiality. The MLS system does not care about integrity of
data, least privilege, or separating processes and objects by their
duty, and has no mechanisms for controlling these security needs.
MLS is a mechanism for maintaining confidentiality of files on the
system, by making sure that unauthorized users cannot read from or
write to them.
Flask solves the inflexibility of MLS-based MAC by separating
the policy enforcement from the policy logic, which is also known
as the security server. In traditional
Flask, the security server holds the security policy logic,
handling the interpretation of security
contexts. Security contexts or labels
are the set of security attributes associated with a process or an
object. Such security labels have the format of <user>:<role>:<type>, for example, system_u:object_r:httpd_exec_t. The SELinux
user system_u is a standard
identity used for daemons. The role object_r is the role for system objects
such as files and devices. The type httpd_exec_t is the type applied to the
httpd executable /usr/sbin/httpd. The label elements user, role, and
type are explained in Section
2.10 SELinux Users and Roles and Section 2.7 TE Rules -
Prior to full integration with the Linux kernel, security
contexts were maintained separately in a file as a set of security identifiers or SIDs. Part of the
change when moving to the Linux 2.6.x kernel is the usage of extended attributes
(EAs) in the file system. SIDs are not
entirely retired, but they are no longer exported to userspace from
the kernel. For example, the kernel has some initial SIDs used by
init during bootstrapping before the
policy is loaded. In addition, libselinux
provides a userspace SID abstraction for applications that enforce
policy, such as dbus-daemon and nscd. Otherwise, users and other programs only
interact with security contexts. To minimize confusion, from here
forward in this guide, the term security
context is used to include the SID.
The security server need only do a look-up with a pair of
contexts on a matrix of type-labeled subjects and objects, and the
result is put in the access vector cache
retrieval on subsequent matching requests.
By adding in a generalized form of TE that is separated into its
own security subsystem, Flask can be flexible in labeling for
transition and access decisions. Instead of being tied to a rigidly
defined lattice of relationships, Flask can define other labels
based on user identity (UID), role
attributes, domain or type attributes, MLS levels, and so
Similarly, access decision computations can be made using
multiple methods in the same decision. These methods could be
lattice models, static matrix lookups, historical decisions,
environmental decisions, or policy logic obtained in real time.
These computations are all handled by the policy engine and cached,
leaving the policy enforcement code available to handle
One other Flask flexibility is that any of these subsystems can
be swapped out for a new or different system, and none of the other
systems are even aware of the change. The abstraction between
policy enforcement and policy decision-making is what makes this
possible. This flexibility gives Red Hat Enterprise Linux
developers the control they need to make the best architecture
decisions without being tied to a particular subsystem.
Figure 1-1. Flask Architecture
describes the Flask architecture, showing the process of an
operation. In this operation, standard DAC has occurred, which
means the subject already has gained access to the object via
regular Linux file permissions based on the UID. The
operation can be anything: reading from or writing to a
file/device, transitioning a process from one type to another type,
opening a socket for an operation, delivering a signal call, and so
A subject, which is a process, attempts to perform an operation
on an object, such as a file, device, process, or socket.
The policy enforcement server gathers the security context from
the subject and object, and sends the pair of labels to the
security server, which is responsible for policy decision
The policy server first checks the AVC, and returns a decision
to the enforcement server.
If the AVC does not have a policy decision cached, it turns to
the security server, which uses the binary policy that is loaded
into the kernel during initialization. The AVC caches the decision,
and returns the decision to the enforcement server, that is, the
If the policy permits the subject to perform the desired
operation on the object, the operation is allowed to proceed.
If the policy does not permit the subject to perform the desired
operation, the action is denied, and one or more avc: denied messages are logged to
$AUDIT_LOG, which is typically /var/log/messages in Red Hat Enterprise Linux.
With the security server handling the policy decision making,
the enforcement server handles the rest of the tasks. In this role,
you can think of the enforcement code as being an object manager. Object management includes labeling
objects with a security context, managing object labels in memory,
and managing client and server labeling.