Red Hat ENTERPRISE LINUX 4 - DEVELOPER TOOLS GUIDE User manual

Red Hat Enterprise Linux 4
Red Hat SELinux Guide

Red Hat Enterprise Linux 4: Red Hat SELinux Guide
Copyright © 2005 by Red Hat, Inc.
Red Hat, Inc.
1801 Varsity Drive
Raleigh NC 27606-2072 USA
Phone: [phone]
Phone: [phone]
Fax: [phone]
PO Box 13588
Research Triangle Park NC 27709 USA
rhel-selg(EN)-4-Print-RHI (2005-02-15-T16:20)
Copyright © 2005 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the
Open Publication License, V1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).
Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright
holder.
Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited
unless prior permission is obtained from the copyright holder.
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other
countries.
All other trademarks referenced herein are the property of their respective owners.
The GPG fingerprint of the [email protected] key is:
CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E

Table of Contents
Introduction to the Red Hat SELinux Guide .................................................................................... i
1. What Is SELinux? .................................................................................................................. i
2. Prerequisites for This Guide .................................................................................................ii
3. Conventions for SELinux Directories and Files ..................................................................iii
4. Document Conventions........................................................................................................iii
5. Code Presentation Conventions ........................................................................................... vi
6. Activate Your Subscription .................................................................................................vii
6.1. Provide a Red Hat Login......................................................................................vii
6.2. Provide Your Subscription Number ....................................................................viii
6.3. Connect Your System..........................................................................................viii
7. More to Come ....................................................................................................................viii
7.1. Send in Your Feedback .......................................................................................viii
I. Understanding SELinux .................................................................................................................. i
1. SELinux Architectural Overview.......................................................................................... 1
1.1. Flask Security Architecture and SELinux.............................................................. 1
1.2. SELinux, an Implementation of Flask ................................................................... 3
2. SELinux Policy Overview..................................................................................................... 5
2.1. What Is Policy? ...................................................................................................... 5
2.2. Where is the Policy? .............................................................................................. 6
2.3. Policy Role in Boot................................................................................................ 7
2.4. File System Security Contexts ............................................................................... 8
2.5. Object Classes and Permissions........................................................................... 10
2.6. TE Rules - Attributes ........................................................................................... 12
2.7. TE Rules - Types.................................................................................................. 17
2.8. TE Rules - Access Vectors................................................................................... 19
2.9. Policy Macros ...................................................................................................... 21
2.10. SELinux Users and Roles .................................................................................. 24
2.11. TE Rules - Constraints....................................................................................... 26
2.12. Special Interfaces and File Systems................................................................... 27
3. Targeted Policy Overview................................................................................................... 29
3.1. What is the Targeted Policy?................................................................................ 29
3.2. Files and Directories of the Targeted Policy ........................................................ 30
3.3. Understanding the File Contexts Files ................................................................. 38
3.4. Common Macros in the Targeted Policy.............................................................. 39
3.5. Understanding the Roles and Users in the Targeted Policy ................................. 42
4. Example Policy Reference - dhcpd.................................................................................... 47
4.1. Policy File Locations ........................................................................................... 47
4.2. Policy Types - dhcpd........................................................................................... 47
4.3. Boolean Values for dhcpd ................................................................................... 51
II. Working With SELinux............................................................................................................... 53
5. Controlling and Maintaining SELinux ............................................................................... 55
5.1. End User Control of SELinux.............................................................................. 55
5.2. Administrator Control of SELinux ...................................................................... 61
5.3. Analyst Control of SELinux ................................................................................ 70
5.4. Policy Writer Control of SELinux ....................................................................... 71
6. Tools for Manipulating and Analyzing SELinux................................................................ 73
6.1. Information Gathering Tools................................................................................ 73
6.2. Using seaudit for Audit Log Analysis................................................................. 76
6.3. Using apol for Policy Analysis............................................................................ 83
6.4. Performance Tuning............................................................................................. 89
7. Compiling SELinux Policy ................................................................................................. 91
7.1. Policy Compile Procedure ................................................................................... 91
7.2. What Happens During Policy Build .................................................................... 93

8. Customizing and Writing Policy......................................................................................... 95
8.1. General Policy Troubleshooting Guidelines ........................................................ 95
8.2. Minor Customizations of the Existing Policy...................................................... 95
8.3. Writing New Policy for a Daemon ...................................................................... 99
8.4. Deploying Customized Binary Policy ............................................................... 101
9. References.................................................................................................................................... 103
III. Appendix ................................................................................................................................... 105
A. Brief Background and History of SELinux...................................................................... 107
Index................................................................................................................................................. 109
Colophon.......................................................................................................................................... 115

Introduction to the Red Hat SELinux Guide
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 (pro-
cesses) 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.
One powerful way of finding information in this guide is the Index. The Index has direct links to
sections on specific terminology, and also features lists of various SELinux syntaxes, as well as what
are/what is and how to entries.
1. What Is SELinux?
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 discre-
tionary 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.

ii Introduction to the Red Hat SELinux Guide
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 Back-
ground 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 sys-
tem. 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 pro-
cesses, 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 exam-
ple, 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.
2. Prerequisites for This Guide
The technical skills required for this guide are not very extensive. The most important skill to have is
an ability to learn technical theories and put them into practice. It helps if you come into this guide with
an idea of what you want to do, such as administrating a set of common services, making user content
from /home/ served via Apache HTTP, manipulating policy to get a custom PHP Web application
running, or writing a policy from to enable a custom application to be protected by SELinux. The
following is helpful to have as you read through this guide:
•Strong working understanding of Linux, especially Red Hat Enterprise Linux.
•If you are going to be administrating services, manipulating or analyzing policy, junior- to mid-
level system administration skills and experience is necessary, such as being a Red Hat Certified
Technician (RHCT) or Red Hat Certified Engineer (RHCE)..
To work with SELinux at that level, you must have the following:
•An understanding of traditional Linux/UNIX security.
•An understanding of how a Linux/UNIX system operates on a lower-level, such as how the kernel
has system calls for various operations (open, close, read, write, ioctl, poll, etc.) An understand-
ing of programming and system theory is useful in writing policy.
•A familiarity with the m4 macro language, which is helpful in understanding some parts of the
SELinux policy.
•Read many of the NSA papers, listed in Chapter 9 References.
•Administrator privileges on the system you have Red Hat Enterprise Linux installed on is neces-
sary to perform many of the operations in this guide. However, there is plenty of useful informa-
tion for end-users.

Introduction to the Red Hat SELinux Guide iii
•Somewhere you can examine and work with the policy sources. This can be a test or development
machine, or possibly a workstation. Many of the examples and explanations in this book assume
that you have the system in front of you to explore while you read.
•Some additional patience. SELinux is a different way of handling access control than many admin-
istrators and users are familiar with.
Information about Red Hat training can be obtained via http://www.redhat.com/training/.
3. Conventions for SELinux Directories and Files
There are two main directories for SELinux policy in /etc/selinux/:
•/etc/selinux/

policyname  /policy/ — the binary policy and runtime configuration files.
•/etc/selinux/

policyname

/src/policy/ — policy sources.
It is possible to have more than one policy existing on the system, although only one
may be loaded at a time. The policy binary files, and possibly source files, are located in
/etc/selinux/

policyname

/, where

policyname

is the name of your policy, such as
targeted, strict, webhost, test, and so forth. The configuration file /etc/selinux/config defines
which policy is used, for example SELINUXTYPE=targeted.
In this document, the convention of $DIRECTORY_TYPE is used instead of the full path to assist in
readability:
•The variable directory $SELINUX_SRC/ is a substitute for the generic directory of
/etc/selinux/

policyname  /src/policy/ and the targeted policy source directory at
/etc/selinux/targeted/src/policy/.
•The variable directory $SELINUX_POLICY/ is a substitute for the generic directory of
/etc/selinux/

policyname

/policy/ and the binary targeted policy directory at
/etc/selinux/targeted/policy/.
An important file is the audit log file. In Red Hat Enterprise Linux, $AUDIT_LOG by default is
/var/log/messages. However, this is configurable via /etc/syslog.conf, and future work on
an audit daemon will handle kernel audit events and log them into a separate file. Because of the
variable nature of where the audit logs are, the variable file $AUDIT_LOG is used as a substitute.
Other important files and directories include $SELINUX_POLICY/booleans and
$SELINUX_POLICY/contexts/, which are both discussed in Section 3.2 Files and Directories of
the Targeted Policy.
The most important file for SELinux is the binary policy file. This file is located at
/etc/selinux/targeted/policy/policy.

XY

. The

XY

represents the two digits of the
policy version. In the case of Red Hat Enterprise Linux 4, this file is policy.18.
4. Document Conventions
When you read this manual, certain words are represented in different fonts, typefaces, sizes, and
weights. This highlighting is systematic; different words are represented in the same style to indicate
their inclusion in a specific category. The types of words that are represented this way include the
following:

iv Introduction to the Red Hat SELinux Guide
command
Linux commands (and other operating system commands, when used) are represented this way.
This style should indicate to you that you can type the word or phrase on the command line
and press [Enter] to invoke a command. Sometimes a command contains words that would be
displayed in a different style on their own (such as file names). In these cases, they are considered
to be part of the command, so the entire phrase is displayed as a command. For example:
Use the cat testfile command to view the contents of a file, named testfile, in the current
working directory.
file name
File names, directory names, paths, and RPM package names are represented this way. This style
should indicate that a particular file or directory exists by that name on your system. Examples:
The .bashrc file in your home directory contains bash shell definitions and aliases for your own
use.
The /etc/fstab file contains information about different system devices and file systems.
Install the webalizer RPM if you want to use a Web server log file analysis program.
application
This style indicates that the program is an end-user application (as opposed to system software).
For example:
Use Mozilla to browse the Web.
[key]
A key on the keyboard is shown in this style. For example:
To use [Tab] completion, type in a character and then press the [Tab] key. Your terminal displays
the list of files in the directory that start with that letter.
[key]-[combination]
A combination of keystrokes is represented in this way. For example:
The [Ctrl]-[Alt]-[Backspace] key combination exits your graphical session and returns you to the
graphical login screen or the console.
text found on a GUI interface
A title, word, or phrase found on a GUI interface screen or window is shown in this style. Text
shown in this style is being used to identify a particular GUI screen or an element on a GUI
screen (such as text associated with a checkbox or field). Example:
Select the Require Password checkbox if you would like your screensaver to require a password
before stopping.
top level of a menu on a GUI screen or window
A word in this style indicates that the word is the top level of a pulldown menu. If you click on
the word on the GUI screen, the rest of the menu should appear. For example:
Under File on a GNOME terminal, the New Tab option allows you to open multiple shell
prompts in the same window.
If you need to type in a sequence of commands from a GUI menu, they are shown like the
following example:
Go to Applications (the main menu on the panel) => Programming => Emacs Text Editor to
start the Emacs text editor.

Introduction to the Red Hat SELinux Guide v
button on a GUI screen or window
This style indicates that the text can be found on a clickable button on a GUI screen. For example:
Click on the Back button to return to the webpage you last viewed.
computer output
Text in this style indicates text displayed to a shell prompt such as error messages and responses
to commands. For example:
The ls command displays the contents of a directory. For example:
Desktop about.html logs paulwesterberg.png
Mail backupfiles mail reports
The output returned in response to the command (in this case, the contents of the directory) is
shown in this style.
prompt
A prompt, which is a computer’s way of signifying that it is ready for you to input something, is
shown in this style. Examples:
$
#
[stephen@maturin stephen]$
leopard login:
user input
Text that the user has to type, either on the command line, or into a text box on a GUI screen, is
displayed in this style. In the following example, text is displayed in this style:
To boot your system into the text based installation program, you must type in the text com-
mand at the boot: prompt.

replaceable

Text used for examples, which is meant to be replaced with data provided by the user, is displayed
in this style. In the following example,

version-number

is displayed in this style:
The directory for the kernel source is /usr/src/kernels/

version-number

/, where

version-number  is the version and type of kernel installed on this system.
Additionally, we use several different strategies to draw your attention to certain pieces of information.
In order of how critical the information is to your system, these items are marked as a note, tip,
important, caution, or warning. For example:
Note
Remember that Linux is case sensitive. In other words, a rose is not a ROSE is not a rOsE.
Tip
The directory /usr/share/doc/ contains additional documentation for packages installed on your
system.

vi Introduction to the Red Hat SELinux Guide
Important
If you modify the DHCP configuration file, the changes do not take effect until you restart the DHCP
daemon.
Caution
Do not perform routine tasks as root — use a regular user account unless you need to use the root
account for system administration tasks.
Warning
Be careful to remove only the necessary partitions. Removing other partitions could result in data
loss or a corrupted system environment.
5. Code Presentation Conventions
In addition to the standard document conventions covered in Section 4 Document Conventions, there
are some additional conventions related specifically to discussing source code:
classname
This is the name of a class in an object-oriented (OO) programming language. For example, the
class com.arsdigita.categorization.CategoryTreeNode.
method name
This is the name of a method in an OO programming language, e.g. the method
getBaseDataObjectType.
function
The name of a function or subroutine, as in a programming language. For example, the function
SecurityLogger.warn().
variable name
The name of a variable. For example, the variable BASE_DATA_OBJECT_TYPE.
option
An option for a software command or Method. For example, a user has been granted read
privileges on an object.
return value
The value returned by a function. For example, a method returns null.

Introduction to the Red Hat SELinux Guide vii
program listing
A literal listing of all or part of a program:
extern void sem_exit (void);
extern struct task_struct *child_reaper;
int getrusage(struct task_struct *, int, struct rusage *);
static void __unhash_process(struct task_struct *p)
{
nr_threads--;
detach_pid(p, PIDTYPE_PID);
detach_pid(p, PIDTYPE_TGID);
if (thread_group_leader(p)) {
detach_pid(p, PIDTYPE_PGID);
detach_pid(p, PIDTYPE_SID);
}
REMOVE_LINKS(p);
p->pid = 0;
}
first term
The first occurrence of a term, such as the first time we introduce a bulletin-board and note its
abbreviated form, bboard.
6. Activate Your Subscription
Before you can access service and software maintenance information, and the support documenta-
tion included in your subscription, you must activate your subscription by registering with Red Hat.
Registration includes these simple steps:
•Provide a Red Hat login
•Provide a subscription number
•Connect your system
The first time you boot your installation of Red Hat Enterprise Linux, you are prompted to register
with Red Hat using the Setup Agent. If you follow the prompts during the Setup Agent, you can
complete the registration steps and activate your subscription.
If you can not complete registration during the Setup Agent (which requires network access), you
can alternatively complete the Red Hat registration process online at http://www.redhat.com/register/.
6.1. Provide a Red Hat Login
If you do not have an existing Red Hat login, you can create one when prompted during the Setup
Agent or online at:
https://www.redhat.com/apps/activate/newlogin.html
A Red Hat login enables your access to:
•Software updates, errata and maintenance via Red Hat Network
•Red Hat technical support resources, documentation, and Knowledgebase
If you have forgotten your Red Hat login, you can search for your Red Hat login online at:

viii Introduction to the Red Hat SELinux Guide
https://rhn.redhat.com/help/forgot_password.pxt
6.2. Provide Your Subscription Number
Your subscription number is located in the package that came with your order. If your package did not
include a subscription number, your subscription was activated for you and you can skip this step.
You can provide your subscription number when prompted during the Setup Agent or by visiting
http://www.redhat.com/register/.
6.3. Connect Your System
The Red Hat Network Registration Client helps you connect your system so that you can begin to get
updates and perform systems management. There are three ways to connect:
1. During the Setup Agent — Check the Send hardware information and Send system package
list options when prompted.
2. After the Setup Agent has been completed — From Applications (the main menu on the panel),
go to System Tools, then select Red Hat Network.
3. After the Setup Agent has been completed — Enter the following command from the command
line as the root user:
•/usr/bin/up2date --register
7. More to Come
The Red Hat SELinux Guide is part of Red Hat’s growing commitment to provide useful and timely
support to Red Hat Enterprise Linux users. As new releases of Red Hat Enterprise Linux are made
available, we make every effort to include both new and improved documentation for you.
7.1. Send in Your Feedback
If you spot a typo in the SELinux Guide, or if you have thought of a way to make this manual better, we
would love to hear from you. Please submit a report in Bugzilla (http://bugzilla.redhat.com/bugzilla)
against the component rhel-selg.
Be sure to mention the manual’s identifier:
rhel-selg(EN)-4-Print-RHI (2005-02-15-T16:20)
If you mention this manual’s identifier, we will know exactly which version of the guide you have.
If you have a suggestion for improving the documentation, try to be as specific as possible. If you
have found an error, please include the section number and some of the surrounding text so we can
find it easily.

I. Understanding SELinux
This part provides an overview and theory of SELinux in general and policy in particular.
Table of Contents
1. SELinux Architectural Overview .................................................................................................. 1
2. SELinux Policy Overview............................................................................................................... 5
3. Targeted Policy Overview............................................................................................................. 29
4. Example Policy Reference - dhcpd .............................................................................................. 47

Chapter 1.
SELinux Architectural Overview
This chapter is an overview of the SELinux architecture, building upon what was discussed in Section
1What 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.
1.1. Flask Security Architecture and SELinux
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. Tradi-
tional 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 se-
curity 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 - Types.
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.xkernel
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 (AVC) for 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 forth.
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

2 Chapter 1. SELinux Architectural Overview
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 requests.
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.
Object
Object (file) Object (file)
server
Security
enforcement
server
Policy
context(a,b)
(file)
Object (device)
context(b)
(user)
Subject
(application,
process)
Subject
context(a)
Subject (user)
Subject
(application)
Object
(process)
Subject (user)
Subject
(application) Object
(process)
avc: denied
no
yes
















Binary policy
(matrix)
AVC
Figure 1-1. Flask Architecture
Figure 1-1 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 UID1. 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 forth.
1. A subject, which is a process, attempts to perform an operation on an object, such as a file, device,
process, or socket.
2. 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 making.
1. This type of access control is also called identify-based access control or IBAC.

Chapter 1. SELinux Architectural Overview 3
3. 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 kernel.
4. If the policy permits the subject to perform the desired operation on the object, the operation is
allowed to proceed.
5. 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.
1.2. SELinux, an Implementation of Flask
SELinux has been through several iterations as part of the process of being incorporated into the Linux
kernel. During this time, the overall architecture has remained the same, but many of the programmatic
details have changed. Some of the reasons for change were: requirements for upstream acceptance;
changes in LSM as part of being accepted into the kernel; and the switch to using xattrs.
As one example of the changes between kernel versions, originally security context was maintained
through a mapping from context to SID, and managed by the security server. In the 2.6.xLinux
kernel, the security context for a file is stored in the xattrs, allowing it to carry around its own SELinux
context.
As an implementation of the Flask architecture, SELinux also served as a reference implementation
of LSM. Originally LSM and SELinux were patches to the 2.4.

x

series of kernels; SELinux was
never able to work as a loadable security module. Therefore, a big part of gaining upstream acceptance
into the mainline Linux kernel required everything from fixing coding practices to changing how
SELinux interacted with the kernel.
Part of the SELinux development team was also instrumental in designing, building, and integrating
LSM into the kernel. SELinux integration into the kernel was the motivation to start the LSM project.
SELinux was an early proof of the ability of LSM to allow security-enhancements to be connected
into, instead of strapped onto, the Linux kernel. Originally, SELinux was a loadable module, but it
became statically compiled into the 2.6.xkernel. It is still an LSM module, using the LSM hooks in
the kernel to control and label. Because of the abstraction layer provided by both the LSM and Flask
frameworks, SELinux is highly configurable and modifiable.
Flask is flexible enough to work in many different environments, and Linux is a natural fit for the
Flask model. Access to the kernel source and a willing, community-driven development process allow
for the best modification to fully support Flask’s objectives. The wide range of platforms Linux runs
on means SELinux is extensively tested. The consensus process of getting SELinux integrated into the
kernel has improved the code and practices. Now that it is integrated, it has a better chance of long-
term success than security-enhancement models that are strapped on-top of the operating system.
There are a few more differences in the specific way SELinux implements Flask in the Linux kernel,
compared to traditional Flask methodology and initial SELinux creation:
1. Under traditional TE, there is a distinction between types and domains. A type is the security
context for a file object, and a domain is the security context for a process. In the SELinux im-
plementation, there is no real distinction programmatically. In SELinux, domains are processes
that have the attribute process, so the term domain is used in the traditional way. Similarly,
the term type is mostly applied to object types, but it can mean both domains and types.

4 Chapter 1. SELinux Architectural Overview
2. The term security server is still used for the sake of clarity, but it is no longer a stand-alone
service. The security server, the AVC, and the policy engine are now all parts of the kernel.

Chapter 2.
SELinux Policy Overview
This chapter is an overview of SELinux policy, some of its internals, and how it works. This chapter
discusses the policy in a more general way, where Chapter 3 Targeted Policy Overview focuses on the
details of the targeted policy as it ships in Red Hat Enterprise Linux. This chapter starts with a brief
overview of what policy is and where it resides. Next, the role of SELinux during boot is discussed.
This is followed by discussions on file security contexts, object classes and permissions, attributes,
types, access vectors, macros, users and roles, constraints, and a brief discussion summarizing special
kernel interfaces.
To see all of the details discussed in this chapter, you must make sure you have installed the policy
source and binary packages for the targeted policy:
•selinux-policy-targeted-sources-

version

•selinux-policy-targeted-

version

Important
When you have the policy sources installed, rpm may assume that you have modified the policy and
may not automatically load a newly installed policy. This occurs if you have ever loaded the policy
from source, that is, run make load,make reload, or make install. New binary policy packages
install policy.

XY

as, for example, $SELINUX_POLICY/policy.18.rpmnew.
If you have not modified the policy or want to use the binary policy package, you can mv
policy.18.rpmnew policy.18, then touch /.autorelabel and reboot. If you have modified the
policy and want to load your modifications, you must upgrade the policy source package and make
load. Policy building is discussed in Chapter 7 Compiling SELinux Policy .
If you have only built the policy but never loaded it, that is, have only run make policy, you should not
run into this situation. The binary policy installs cleanly, knowing that you are not running a custom
policy.
Work is ongoing to improve package installation logic so the entire process is automated by rpm.
Expect this to be included in a future update to Red Hat Enterprise Linux 4.
2.1. What Is Policy?
Policy is the set of rules that guide the SELinux security engine. It defines types for file objects and
domains for processes, uses roles to limit the domains that can be entered, and has user identities to
specify the roles that can be attained. A domain is what a type is called when it is applied to a process.
A type is a way of grouping together like items based on their fundamental security sameness. This
doesn’t necessarily have to do with the unique purpose of an application or the content of a document.
For example, an object such as a file can have any type of content and be for any purpose, but if it
belongs to a user and lives in that user’s home directory, it is considered to be of a specific security
type, user_home_t.
These object types gain their sameness because they are accessible in the same way by the same set of
subjects. Similarly, processes tend to be of the same type if they have the same permissions as other
subjects. In the targeted policy, programs that run in the unconfined_t domain have an executable
with a type such as sbin_t. From an SELinux perspective, that means they are all equivalent in terms
of what they can and cannot do on the system.

6 Chapter 2. SELinux Policy Overview
For example, the binary executable file object at /usr/bin/postgres has the type of
postgresql_exec_t. All of the targeted daemons have their own *_exec_t type for their
executable applications. In fact, the entire set of PostgreSQL executables such as createlang,
pg_dump, and pg_restore have the same type, postgresql_exec_t, and they transition to the
same domain, postgresql_t, upon execution.
The policy defines various rules that say how each domain may access each type. Only what is specif-
ically allowed by the rules is permitted. By default every operation is denied and audited, meaning it
is logged in $AUDIT_LOG, such as /var/log/messages. Policy is compiled into binary format for
loading into the kernel security server, and as the security server hands out decisions, these are cached
in the AVC for performance.
Policy can be administratively defined, either by modifying the existing files or adding local TE and
file context files to the policy tree. Such a new policy can be loaded into the kernel in real time.
Otherwise, the policy is loaded during boot by init, as explained in Section 2.3 Policy Role in Boot.
Ultimately, every system operation is determined by the policy and the type labeling of the files.
Important
After loading a new policy, it is recommended to restart any services that may have new or changed
labeling. For the most part, this is only the targeted daemons, as listed in Section 3.1 What is the
Targeted Policy?.
SELinux is an implementation of domain-type access control, with role-based limiting. The policy
specifies the rules in that environment. It is written in a simple language created specifically for writing
security policy. Policy writers use m4 macros to capture common sets of low-level rules. There are a
number of m4 macros defined in the existing policy, which assist greatly in writing new policy. These
rules are preprocessed into many additional rules as part of building policy.conf, which is compiled
into the binary policy.
The files are divided into various categories in a policy tree at $SELINUX_SRC/. This is covered in
Section 3.2 Files and Directories of the Targeted Policy. Access rights are divided differently among
domains, and no domain is required to act as a master for all other domains. Entering and switching
domains is controlled by the policy, through login programs, userspace programs such as newrole,
or by requiring a new process execution in the new domain, called a transition.
2.2. Where is the Policy?
There are two components to the policy, the binary tree and the source tree. The binary tree comes from
the selinux-policy-

policyname

package and supplies the binary policy file. Alternately,
the binary policy can be built from source when the selinux-policy-
 policyname  -sources
package is installed. For Red Hat Enterprise Linux 4 the

policyname

is targeted. Directory
conventions for this guide are explained in Section 3 Conventions for SELinux Directories and Files.
•/etc/selinux/targeted/ — this is the root folder for the targeted policy, and contains both the
binary and source trees.
•/etc/selinux/targeted/policy/ — the binary policy file policy.

XY

is here. In this
guide, the variable $SELINUX_POLICY/ is used for this directory.
•/etc/selinux/targeted/src/policy/ — this is the location of the policy source tree. For
details about these sub-directories, read Section 3.2 Files and Directories of the Targeted Policy. In
this guide, the variable $SELINUX_SRC/ is used for this directory.
•/etc/selinux/targeted/contexts/ — location of the security context information and con-
figuration files, which are used during runtime by various applications. This directory contains: