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.
