Welcome to the Red Hat SELinux Guide. This guide addresses the complex world of SELinux
policy, and has the goal of teaching you how to understand, use, administer,
and troubleshoot SELinux in a Red Hat Enterprise Linux environment. SELinux, an implementation of
mandatory access control (MAC) in
the Linux kernel, adds the ability to administratively define policies on
all subjects (processes) and
objects (devices, files, and signaled processes).
These terms are used as an abstract when discussing actors/doers and their
targets on a system. This guide commonly refers to processes, the source of
an operations, and objects, the target of an operation.
This guide opens with a short explanation of SELinux, some assumptions about
the reader, and an explanation of document conventions. The first part of
the guide provides an overview of the technical architecture and how policy
works, specifically the policy that comes with Red Hat Enterprise Linux called the
targeted policy. The second part focuses on working
with SELinux, including maintaining and manipulating your systems, policy
analysis, and compiling your custom policy. Working with some of the
daemons that are confined by the targeted policy is discussed throughout.
These daemons are collectively called the targeted
daemons.
This section is a very brief overview of SELinux. More detail is given in
Part I Understanding SELinux and Appendix A Brief Background and History of SELinux.
Security-enhanced Linux
(SELinux) is an implementation of a
mandatory access control mechanism. This mechanism
is in the Linux kernel, checking for allowed operations after standard Linux
discretionary access controls are checked.
To understand the benefit of mandatory access control (MAC)
over traditional discretionary access control (DAC), you
need to first understand the limitations of DAC.
Under DAC, ownership of a file object provides potentially crippling or
risky control over the object. A user can expose a file or directory to a
security or confidentiality breach with a misconfigured
chmod command and an unexpected propagation of access
rights. A process started by that user, such as a CGI script, can do
anything it wants to the files owned by the user. A compromised Apache HTTP
server can perform any operation on files in the Web group. Malicious or
broken software can have root-level access to the entire system, either by
running as a root process or using setuid or
setgid.
Under DAC, there are really only two major categories of users,
administrators and non-administrators. In order for services and programs
to run with any level of elevated privilege, the choices are few and course
grained, and typically resolve to just giving full administrator access.
Solutions such as ACLs (access control
lists) can provide some additional security for allowing
non-administrators expanded privileges, but for the most part a root account
has complete discretion over the file system.
A MAC or non-discretionary access control framework
allows you to define permissions for how all processes (called
subjects) interact with other parts of the system
such as files, devices, sockets, ports, and other processes (called
objects in SELinux). This is done through an
administratively-defined security policy over all processes and objects.
These processes and objects are controlled through the kernel, and security
decisions are made on all available information rather than just user
identity. With this model, a process can be granted just the permissions it
needs to be functional. This follows the principle of least
privilege. Under MAC, for example, users who have exposed
their data using chmod are protected by the fact that
their data is a kind only associated with user home directories, and
confined processes cannot touch those files without permission and purpose
written into the policy.
SELinux is implemented in the Linux kernel using the LSM
(Linux Security Modules) framework. This is only the
latest implementation of an ongoing project, as detailed in Appendix A Brief Background and History of SELinux. To support fine-grained access
control, SELinux implements two technologies: Type Enforcement™
(TE) and a kind of role-based access
control (RBAC), which are discussed in
Chapter 1 SELinux Architectural Overview.
Type Enforcement involves defining a type for every
subject, that is, process, and object on the system. These types are
defined by the SELinux policy and are contained in
security labels on the files themselves, stored in the extended
attributes (xattrs) of
the file. When a type is associated with a processes, the type is called a
domain, as in, "httpd is in the domain of
httpd_t." This is a terminology difference
leftover from other models when domains and types were handled separately.
All interactions between subjects and objects are disallowed by default on
an SELinux system. The policy specifically allows certain operations. To
know what to allow, TE uses a matrix of domains and object types derived
from the policy. The matrix is derived from the policy rules. For example,
allow httpd_t net_conf_t:file { read getattr lock ioctl
}; gives the domain associated with httpd the
permissions to read data out of specific network configuration files such as
/etc/resolv.conf. The matrix clearly defines all the
interactions of processes and the targets of their operations.
Because of this design, SELinux can implement very granular access controls.
For Red Hat Enterprise Linux 4 the policy has been designed to restrict only a
specific list of daemons. All other processes run in an unconfined state.
This policy is designed to help integrate SELinux into your development and
production environment. It is possible to have a much more strict policy,
which comes with an increase in maintenance complexity.
