Red Hat ENTERPRISE LINUX 4 - SELINUX 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: +1 919 754 3700
Phone: 888 733 4281
Fax: +1 919 754 3701
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 purposesis 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 security@redhat.com 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 (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.
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 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.
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 understanding 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 information 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
policynameis 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
. TheXYrepresents 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 command 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-numberis displayed in this style:
The directory for the kernel source is /usr/src/kernels/
version-number/, where
version-numberis 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 documentation 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
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.
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. 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 - 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.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 (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.x Linux
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.x kernel. 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 longterm 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 implementation, 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 specifically 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
policynameis 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:
Chapter 2. SELinux Policy Overview 7
• *_context* and default_type — various contexts used by applications, such as the
userhelper_context used by userhelper.
• files/* — the file file_contexts contains the default contexts for the whole file system.
This is what restorecon references when relabeling. The file media contains the default contexts for media devices such as the CD-ROM and floppy disk.
• users/* — in the targeted policy, only the file root is in this directory. These files are used for
determining context on login, which is system_r:unconfined_t for root.
• booleans — this is where the runtime Booleans are configured. This is the canonical configuration
file when Boolean values are changed.
To help applications that need the various SELinux paths, libselinux has a number of functions
that return the paths to the different configuration files and directories. This keeps applications from
having to hard code the paths, especially since the active policy location is dependent on the setting
in /etc/selinux/config. The list of functions is available from the manual page which you can
view with the command man 3 selinux_binary_policy_path.
2.3. Policy Role in Boot
SELinux plays an important role early in system start-up. Since all of the processes must be labeled
with their proper domain, init does some essential actions early in the boot process that keep labeling
and policy enforcement in sync.
1. After the kernel has been loaded during boot, the initial process is assigned the predefined initial
SID kernel. Initial SIDs are used for bootstrapping before the policy is loaded.
2. /sbin/init mounts /proc/, then looks for the selinuxfs file system type. If it is present, that
means SELinux is enabled in the kernel.
3. If init does not find SELinux in the kernel, finds it is disabled via the selinux=0 boot parameter, or if /etc/selinux/config specifies that SELINUX=disabled, boot proceeds with a
non-SELinux system.
At the same time, init sets the enforcing status if it is different from the setting in
/etc/selinux/config. This happens when a parameter is passed during boot. The default
mode is permissive until the policy is loaded, then enforcement is set by the configuration file or
by the parameters enforcing=0 or enforcing=1.
4. If SELinux is present, /selinux/ is mounted.
5. The kernel checks /selinux/policyvers for the supported policy version. init looks into
/etc/selinux/config to see which policy is active, such as the targeted policy, and loads the
associated file at $SELINUX_POLICY/policy.
version
.
If the binary policy is not the version supported by the kernel, init attempts to load the policy
file if it is a previous version. This provides backward compatibility with older policy versions.
If the local settings in /etc/selinux/targeted/booleans are different from those compiled
in the policy, init modifies the policy in memory based on the local settings prior to loading the
policy into the kernel.
6. Now that the policy is loaded, the initial SIDs are mapped to security contexts in the policy, as
defined in $SELINUX_SRC/initial_sid_contexts. In the case of the targeted policy, the new
domain is user_u:system_r:unconfined_t. The kernel can now begin to get security contexts
dynamically from the in-kernel security server.
8 Chapter 2. SELinux Policy Overview
7. init then re-executes itself so that it can transition to a different domain, if the policy defines
it. For the targeted policy, there is no transition defined and init remains in the unconfined_t
domain.
8. At this point, init continues with its normal boot.
The reason for init to re-execute itself is to accommodate stricter SELinux policy controls. The
objective of a re-execution is to transition to a new domain with its own granular rules. The only way
a process can gain a domain is during execution, meaning such programs are the only entry points
into the domains. For example, if the policy has a specific domain for init such as init_t, there has
to be a method to get from the initial SID, such as kernel, to the proper runtime domain for init.
Because this transition may need to occur, init is coded to re-execute itself after loading the policy.
This transition with init happens if the rule domain_auto_trans(kernel_t, init_exec_t,
target_domain_t) is present in the policy. This rule states that an automatic transition occurs
on anything executing from the kernel_t domain that executes a file of type init_exec_t. When
this execution occurs, the new process is assigned the domain
target_domain_t
, using an actual
target domain such as init_t.
2.4. File System Security Contexts
This section covers how file system security contexts are defined and stored.
SELinux stores file security labels in xattrs1. For more information about xattrs, read the manual pages
for attr(5), getfattr(1), and setfattr(1). Xattrs are stored as name-value property pairs associated with files. SELinux uses the security.selinux attribute. The xattrs can be stored with
files on a disk or in memory with pseudo file systems. Currently, most file system types support the
API for xattr, which allows for retrieving attribute information with getxattr(2).
Some non-persistent objects can be controlled through the API. The pseudo-tty system controlled
through /dev/pts is manipulated through setxattr(2), enabling programs such as sshd to change
the context of a tty device. Information about the tty is exported and available through getxattr(2).
However, libselinux provides a more useful set of functions layered on top of the xattr API, such
as getfilecon(3), setfilecon(3), and setfscreatecon(3).
Tip
It is recommended to use libselinux when managing file attributes in SELinux programmatically.
There are two approaches to take for storing file security labels on a file system, such as ext2 or ext3.
One approach is to label every file system object (all files) with an individual security attribute2. Once
these labels are on the file system, the xattrs become authoritative for holding the state of security
labels on the system.
The other option is to label the entire file system with a single security attribute. This is called genfs
labeling. One example of this is with ISO9660 file systems, which are used for CD-ROMs and .iso
files. This example from $SELINUX_SRC/genfs_contexts defines the context for every file on an
ISO9660 file system.
1. Extended attributes are also called EAs. To be more concise, the term xattr is used in this guide.
2. These are defined initially for the system in $SELINUX_SRC/file_contexts/types.fc.
This file uses regular expression matching to associate the files on a particular path
with a particular security label. These contexts are rendered into the installed version at
/etc/selinux/targeted/contexts/files/file_contexts, and are used during installation of
the operating system and software packages, or for checking or restoring files to their original state.
Chapter 2. SELinux Policy Overview 9
genfscon iso9660 / system_u:object_r:iso9660_t
The file genfs_contexts has labels to associate with the most common mounted file systems that
do not support xattrs.
You can set the context at the time of mounting the file system with the option -o
context=
user :role :type
. A complete list of file system types can be found at
$SELINUX_SRC/types/file.te. This option is also known as mountpoint labeling and is new in
the 2.6.x kernel. Mountpoint labeling occurs in the kernel memory only, the labels are not written to
disk. This example overrides the setting in genfs_contexts that would normally mount the file
system as nfs_t:
mount -t nfs -o context=user_u:object_r:user_home_t \
hostname :/shares/homes/ /home/
The -o context= option is useful when mounting file systems that do not support extended attributes, such as a floppy or hard disk formatted with VFAT, or systems that are not normally running
under SELinux, such as an ext3 formatted disk from a non-SELinux workstation. You can also use
-o context= on file systems you do not trust, such as a floppy. It also helps in compatibility with
xattr-supporting file systems on earlier 2.4.
!x"
kernel versions. Even where xattrs are supported,
you can save time not having to label every file by assigning the entire disk one security context.
Two other options are -o fscontext= and -o defcontext=, both of which are mutually exclusive
of the context option. This means you can use fscontext and defcontext with each other, but
neither can be used with context.
The fscontext option works for all file systems, regardless of their xattr support. The fscontext
option sets the overarching file system label to a specific security context. This file system label is
separate from the individual labels on the files. It represents the entire file system for certain kinds
of permission checks, such as during mount or file creation. Individual file labels are still obtained
from the xattrs on the files themselves. The context option actually sets the aggregate context that
fscontext provides, in addition to supplying the same label for individual files.
You can set the default security context for unlabeled files using defcontext. This overrides the
value set for unlabeled files in the policy and requires a file system that supports xattr labeling. This
example might be for a shared volume that gets file drops of security quarantined code, so the dropped
files are labeled as being unsafe and can be controlled specially by policy:
mount -t ext3 defcontext=user_u:object_r:insecure_t \
/shares/quarantined
This all works because SELinux acts as a transparent layer for the mounted file system. After parsing
the security options, SELinux only passes normal file system specific code to the mounted file system.
SELinux is able to seamlessly handle the text name-value pairs that most file systems use for mount
options. File systems with binary mount option data, such as NFS and SMBFS, need to be handled as
special cases. Currently, NFSv3 is the only one supported.
2.4.1. Security Contexts and the Kernel
SELinux uses LSM hooks in the kernel in key locations, where they interject access vector decisions.
For example, there is a hook just prior to a file being read by a user, where SELinux steps from the
normal kernel workflow to request the AVC decision. This mainly occurs between a subject (a process
such as less) and an object (a file such as /etc/ssh/sshd_config) for a specific permission need
(such as read).
Based on the result read back from the AVC, the hook either continues the workflow or returns EACCES, that is, Permission denied.
10 Chapter 2. SELinux Policy Overview
The way SELinux implements its label in the xattr is different from other labeling schemes. SELinux
stores its labels in human-readable strings. This provides a meaningful label with the file that can help
in backup, restoration, and moving files between systems. Standard attributes do not provide a label
that has continuous meaning for the file.
In this example under the targeted policy, the policy does not specify anything about files created by
unconfined_t in the directory /tmp, so the files inherit the context from the parent directory:
id -Z
root:system_r:unconfined_t
ls -dZ /tmp
drwxrwxrwt root root system_u:object_r:tmp_t /tmp/
touch /tmp/foo
ls -Z /tmp/foo
-rw-r--r-- root root root:object_r:tmp_t /tmp/foo
In this example under a different policy, the policy explicitly states that files created by user_t in
/tmp have a type of user_tmp_t:
id -Z
user_u:staff_r:user_t
ls -dZ /tmp
drwxrwxrwt usera usera system_u:object_r:tmp_t /tmp/
touch /tmp/foo
ls -Z /tmp/foo
-rw-r--r-- usera usera root:object_r:user_tmp_t /tmp/foo
This finer grained control is implemented via policy using the tmp_domain() macro, which defines
a temporary type per domain. In this macro, the variable $1_tmp_t is expanded by substituting the
subject’s type base, so that user_t creates files with a type of user_tmp_t.
Having separate types for /tmp/ protects a domain’s temporary files against tampering or disclosure
by other domains. It also protects against misdirection through a malicious symlink. In the targeted
policy, the confined daemons have separate types for their temporary files, keeping those daemons
from interfering with other /tmp/ files.
A privileged application can override any stated labeling rule by writing a security context to
/proc/self/attr/fscreate using setfscreatecon(3). This action must still be allowed by
policy. The context is then used to label the next newly created file object, and the fscreate is
automatically reset after the next execve or through setfscreatecon(NULL). This ensures that a
program starts in a known state without having to be concerned what context was left by the previous
program in /proc/self/attr/fscreate.
2.5. Object Classes and Permissions
SELinux defines a number of classes for objects, making it easier to group certain permissions by
specific classes. Here are some examples:
• File related classes include filesystem for file systems, file for files, and dir for directories.
Each class has it’s own associated set of permissions. The filesystem class can mount, unmount,
get attributes, set quotas, relabel, and so forth. The file class gains the common file permissions
such as read, write, get and set attributes, lock, relabel, link, rename, append, etc.
• Network related classes include tcp_socket for TCP sockets, netif for network interfaces, and
node for network nodes. The netif class, for example, can send and receive on TCP, UDP and
raw sockets (tcp_recv, tcp_send, udp_send, udp_recv, rawip_recv, and rawip_send.)
Chapter 2. SELinux Policy Overview 11
The object classes have matching declarations in the kernel, meaning that it is not trivial to add or
change object class details. The same thing is true for permissions. Development work is ongoing to
make it possible to register and unregister classes and permissions dynamically.
Permissions are the actions that a subject can take on an object, if the policy allows it. These permissions are the access requests that SELinux actively allows or denies.
There are several common sets of permissions defined in the targeted policy, in
$SELINUX_SRC/flask/access_vectors. These allow the actual classes to inherit the sets,
instead of rewriting the same permissions across multiple classes:
# Define a common prefix for file access vectors.
#
common file
{
ioctl
read
write
create
getattr
setattr
lock
relabelfrom
relabelto
append
unlink
link
rename
execute
swapon
quotaon
mounton
}
# Define a common prefix for socket access vectors.
#
common socket
{
# inherited from file
ioctl
read
write
create
getattr
setattr
lock
relabelfrom
relabelto
append
# socket-specific
bind
connect
listen
accept
getopt
setopt
shutdown
recvfrom
sendto
recv_msg
12 Chapter 2. SELinux Policy Overview
send_msg
name_bind
}
# Define a common prefix for ipc access vectors.
#
common ipc
{
create
destroy
getattr
setattr
read
write
associate
unix_read
unix_write
}
Following the common sets are all the access vector definitions. The definition is structured this way:
class
#
class_name$[ inherits#common_name$] {#permission_name$... }.
A good example is the dir class, which inherits the permissions from the file class, and has
additional permissions on top:
class dir
inherits file
{
add_name
remove_name
reparent
search
rmdir
}
Another example is the class for tcp_socket, which inherits the socket set plus having its own set
of additional permissions:
class tcp_socket
inherits socket
{
connectto
newconn
acceptfrom
node_bind
}
2.6. TE Rules - Attributes
Policy attributes identify as groups sets of security types that have a similar property. These groups
can be controlled by fewer, overarching rules. The relationship is many-to-many: a type can have any
amount of attributes, and an attribute can be associated with any number of types.
The declarations file $SELINUX_SRC/attrib.te is well documented in the comment blocks. The
attribute declaration syntax is: attribute
#
identifier
$
:
## Samples from $SELINUX_SRC/attrib.te
# The domain attribute identifies every type that can be
Chapter 2. SELinux Policy Overview 13
# assigned to a process. This attribute is used in TE rules
# that should be applied to all domains, e.g. permitting
# init to kill all processes.
attribute domain;
# Identifies all default types assigned to packets received
# on network interfaces.
attribute netmsg_type;
Here are a few noteworthy attributes. Information about these was obtained through policy analysis
using apol, part of the setools package. You can read more about this in Section 6.3 Using apol for
Policy Analysis.:
httpdcontent
The purpose of this attribute is to group together the various types associated with the policy
for Apache HTTP. Because of the complexity of the httpd configuration, the targeted policy
includes Boolean values that allow you to grant blanket permissions for httpd content types.
This helps Web applications and built-in scripting, such as PHP for Apache HTTP, to work with
the content. The types in this attribute are:
# This is an aliasing relationship
httpd_sys_content_t: httpd_sysadm_content_t, \
httpd_user_content_t
# These types handle different permissions sets for scripts
httpd_sys_script_ro_t
httpd_sys_script_rw_t
httpd_sys_script_ra_t
The first line in the attribute group specifies that httpd_sys_content_t is an alias for
httpd_sysadm_content_t and httpd_user_content_t.
file_type
This attribute is for all the types that are assigned to files, allowing for easier association of all
file types to various kinds of file system needs. This attribute makes it more convenient to allow
specific domains access to all file types. The list of types associated with the file_type attribute
is greater than 170 types:
...
device_t
xconsole_device_t
file_t
default_t
root_t
mnt_t
home_root_t
lost_found_t
boot_t
system_map_t
boot_runtime_t
tmp_t
etc_t: hotplug_etc_t
shadow_t
ld_so_cache_t
etc_runtime_t
fonts_t
etc_aliases_t
net_conf_t: resolv_conf_t
lib_t
shlib_t
...
14 Chapter 2. SELinux Policy Overview
netif_type, port_type, and node_type
These attributes relate to network activity by domains. The netif_type identifies the types
associated with network interfaces, allowing policy to control sending, receiving, and various
operations on the interface:
netif_t
netif_eth0_t
netif_eth1_t
netif_eth2_t
netif_lo_t
netif_ippp0_t
netif_ipsec0_t
netif_ipsec1_t
netif_ipsec2_t
The port_type attribute is associated with all types that are assigned to port numbers. This allows SELinux to control port binding, meaning daemons are restricted in using a port depending
on the type assigned to the port:
dns_port_t
dhcpd_port_t
http_cache_port_t
port_t
reserved_port_t
http_port_t
pxe_port_t
smtp_port_t
mysqld_port_t
rndc_port_t
ntp_port_t
portmap_port_t
postgresql_port_t
snmp_port_t
syslogd_port_t
The node_type is for types assigned to network nodes or hosts, allowing SELinux to control
traffic to and from the node:
node_t
node_lo_t
node_internal_t
node_inaddr_any_t
node_unspec_t
node_link_local_t
node_site_local_t
node_multicast_t
node_mapped_ipv4_t
node_compat_ipv4_t
fs_type
This attribute identifies all types assigned to file systems, including non-persistent file systems.
The fs_type attribute is used in TE rules to allow most domains to obtain overall file system
statistics, and for some specific domains to mount any file system. Here are the SELinux file
types that are part of fs_type:
devpts_t: sysadm_devpts_t, staff_devpts_t, user_devpts_t
fs_t
eventpollfs_t
Chapter 2. SELinux Policy Overview 15
futexfs_t
bdev_t
usbfs_t
nfsd_fs_t
rpc_pipefs_t
binfmt_misc_fs_t
tmpfs_t
autofs_t
usbdevfs_t
sysfs_t
iso9660_t
romfs_t
ramfs_t
dosfs_t
cifs_t: sambafs_t
nfs_t
proc_t
security_t
exec_type
This attribute groups together all types that are assigned to entry point executables. Any TE rules
and assertions that should be applied to all entry point executables use this attribute. Here are the
domains in this attribute:
ls_exec_t
shell_exec_t
httpd_exec_t
httpd_suexec_exec_t
httpd_php_exec_t
httpd_helper_exec_t
dhcpd_exec_t
hotplug_exec_t
initrc_exec_t
run_init_exec_t
init_exec_t
ldconfig_exec_t
mailman_queue_exec_t
mailman_mail_exec_t
mailman_cgi_exec_t
depmod_exec_t
insmod_exec_t
update_modules_exec_t
sendmail_exec_t
mysqld_exec_t
named_exec_t
ndc_exec_t
nscd_exec_t
ntpd_exec_t
ntpdate_exec_t
portmap_exec_t
postgresql_exec_t
rpm_exec_t
snmpd_exec_t
squid_exec_t
syslogd_exec_t
udev_exec_t
udev_helper_exec_t
winbind_exec_t
ypbind_exec_t
16 Chapter 2. SELinux Policy Overview
mta_delivery_agent
This attribute allows for flexibility in choosing a mail transfer agent (MTA) such as sendmail
or postfix. Rules allow it to perform mail handling and take tasks from mailman. However,
this attribute is not used in the targeted policy since none of the MTAs are targeted daemons for
Red Hat Enterprise Linux 4.
domain
This attribute is for all types that can be assigned to a process. This is the method for identifying
what is a domain in SELinux. In other Type Enforcement systems, domains may be implemented
separately from types. In SELinux, domains are essentially types with the domain attribute.
This attribute allows you to have rules that can be applied to all domains, such as allowing init
to send signals to all processes. Another example is the following rule that allows all processes
to perform a search on directory objects that have a type of var_t or var_run_t, that is, the
directories /var and /var/run:
allow domain { var_run_t var_t } : dir search ;
Here are the domains covered by this attribute:
unconfined_t: kernel_t, init_t, initrc_t, sysadm_t, rpm_t, \
rpm_script_t, logrotate_t
mount_t
httpd_t
httpd_sys_script_t
httpd_suexec_t
httpd_php_t
httpd_helper_t
dhcpd_t
ldconfig_t
mailman_queue_t
mailman_mail_t
mailman_cgi_t
system_mail_t
mysqld_t
named_t
ndc_t
nscd_t
ntpd_t
portmap_t
postgresql_t
snmpd_t
squid_t
syslogd_t
winbind_t
ypbind_t
reserved_port_type
This attribute identifies all the types that are assigned to any of the reserved network ports, that
is, ports numbered lower than 1024. The attribute is used to control binding. An example binding
rule is followed here by the types that are part of this attribute:
# The allow rule permits the domain portmap_t to bind to a
# port with a type of portmap_port_t, which is one of the
# types identified by the reserved_port_type attribute. The
# dontaudit rule tells SELinux to never audit the access of
# portmap_t to a reserved_port_type.
allow portmap_t portmap_port_t:{ udp_socket tcp_socket } \
name_bind;
dontaudit portmap_t reserved_port_type:tcp_socket name_bind;
# Types associated with the reserved_port_type attribute
Loading...