Anda di halaman 1dari 38

SELinux For Dummies

Gary Smith, EMSL, Pacific Northwest National

A Little Context

Cyber Security is all about managing risk.

How do you think about managing risk?
The Five Golden Principles of Security
Know your system
Principle of Least Privilege
Defense in Depth
Protection is key but detection is a must.
Know your enemy.


Most operating systems use what is called Discretionary

Access Control (DAC) to control how processes interact
with files and the way processes interact with each other.
On operating systems using DAC, users control the
permissions of the files they own.
The kernel enforces access control decisions based on
these security properties.

What could go wrong?

If a bug in the Apache web server allows privilege

escalation to root, the whole system has the potential to
be compromised.
Ordinary security policy is too simplistic and there is no
way to enforce least privilege (even though weve layered
on many ways to try to enforce least privilege).

Enter SELinux

One way of solving these problems is SELinux.

SELinux adds additional access control beyond what is
offered with traditional DAC.
Processes and resources have additional security
properties associated with them and the security policy in
the kernel is flexible and easily changed.
SELinux adds Mandatory Access Control (MAC) to the
Linux kernel.
A general purpose MAC architecture needs the ability to
enforce an administratively-set security policy over all
processes and files in the system, basing decisions on
labels containing a variety of security-relevant

MAC vs. DAC Smackdown

In a DAC model, file and resource decisions are based

solely on user identity and ownership of the objects.
Each user and program run by that user has complete
discretion over the user's objects.
Malicious, flawed, or misconfigured software can do
anything with the files and resources it controls through
the user that started the process.
If the user is the super-user or the application is setuid or
setgid to root, the process can have root level control over
the entire file system.
A MAC system does not suffer from these problems.
The system manager can administratively define a
security policy over all processes and objects.

MAC vs. DAC Smackdown (cont.)

Interactions among processes, objects and other

processes is controlled through the kernel security
Decisions by the kernel security module are based on all
the security relevant information available from the policy,
and not just authenticated user identity.
MAC allows you to provide granular permissions for all
users, programs, processes files, directories, devices,
socket, ports, fifos, etc.

SELinux Benefits

All processes and files are labeled with a type. A type

defines a domain for processes, and a label for files.
Running in their own domains separates processes from
each other, and SELinux policy rules define how
processes interact with files, as well as how processes
interact with each other.
Access is only allowed if a SELinux policy rule exists that
specifically allows it.
SELinux implements fine-grained access control.
SELinux policy is not set at user discretion but rather is
administratively-defined and enforced system-wide.

SELinux Forms of Access Control

SELinux has four forms of access control:

Targeted Enforcement (TE)

Role-Based Access Control (RBAC) and
Multi-Level Security (MLS)

What SELinux is not

SELinux is not:
A replacement for passwords, firewalls, or other security systems.
Antivirus software.
An all-in-one security solution.

Getting into SELinux The Security Context

Everything in SELinux revolves around the Security

In SELinux parlance, processes are called subjects and
files, directories, sockets, FIFOs, etc. are called objects.
There are no verbs, adverbs, adjectives or
prepositions in SELinux.
Every subject (process) and object (file on the computer)
has a security context associated with it.
This context has different names depending on what it is
attached to.
Its called a file context when it is associated with a file.
If its associated with a process, its called a domain

Looking at the Security Context

Now lets look at what makes up a security context.

The security context is made up of 3 or 4 components
separated by :
Most discussions of security contexts start at the left and
work towards the right.
Im going to do it in reverse order and start on right and
work towards the left.
The fields in a security context are:
A sample security context:

-Z is your friend

How do you see a files or process security context?

Use the Z option with Linux commands.
So, ls Z will show you the security context files and ps
efZ will show you the security context for the running
Want to know what your security context is? Do id Z.
One of the powerful features of SELinux is that
applications do not need to be aware of SELinux.
Of the hundreds/thousands of rpm packages in RHEL 6,
only about 50 are compiled with SELinux awareness in

SELinux Aware Applications

Applications used to view or manipulate security contexts

(Core Utilities). Examples of this are the ls for viewing
file context, ps for viewing process context, and find for
finding files based on context.
Programs required to set user session security context.
The login programs are the most obvious programs for
this: login, sshd, display manager such as gdm, and
The SELinux core programs. These are used to
control/manipulate security context such as chcon,
setfiles, restorecon Those used to manipulate
policy such as load_policy, check_policy,
check_module, semodule, semanage,
setenforce, getenforce, setsebool,

mv versus cp: How to get yourself into
Context Hell

The mv command will attempt to maintain the security

context of the file when it is moved to a different directory.
This might cause some confusion, but this works the
same way as with discretionary access control.
The cp command acts a little differently.
If a file exists that you are copying over, the new file will
maintain the file context of the previous file.
If the file does not exist, it will either get the security
context of the directory, or, if a file transition rule exists, it
will transition the context to follow the rule.

mv versus cp: How to get yourself into
context hell (cont.)

cp has an option to preserve the mode, ownership, and

timestamps, and context.
If you want to copy a file and explicitly set the context, use
the Z option followed by the context.

SELinux Modes

SELinux has three modes of operation:

Disabled - SELinux enforcement entirely turned off and also the
creation of proper labels on the files no longer takes place.
Permissive - The kernel will also continue to create properly
labeled files, watch all system access checks, and report Access
Violations in the form of Access Vector Cache (AVC) messages
but will allow the access.
Enforcing - This tells the system to run with SELinux labeling files
with proper contexts, watching all system access checks, stopping
all "Denied" access, and logging all AVC violations.
To see the current SELinux mode, do getenforce or

Setting Up SELinux

How do you go about enabling SELinux? If this is a fresh

install, youll be presented with an option to enable it on
the first boot after installation and Bobs your uncle.
More than likely, the system you wish to bring SELinux up
on has been running for some time. The first step is to
determine the state of SELinux on the system.
Edit the file /etc/selinux/config. Change the lines to look
like this:
You could go for whole enchilada and go straight from
disabled mode to enforcing mode. I do not recommend
this unless you enjoy hordes of enraged users darkening
your doorway.

Enabling SELinux

If the system has been running in disabled mode, newly

created file system objects will not be labeled with a
security context.
To set the file systems to be relabeled on reboot, do

touch /.autorelabel

and reboot.

Troubleshooting SELinux

After you reboot the system having set up SELinux to run

in permissive mode, you are going to get permission error
messages in the audit file, /var/log/audit/audit.log.
To get at the AVC messages, do
ausearch i m AVC,USER_AVC sv no
Heres a list of things to look at when you are trying to
resolve an SELinux access problem.
Wrong Subject Context
Wrong Object Context
Right Subject and Object Context but No Access
An Intrusion Attempt

Wrong Subject Context

The program is running with the wrong subject context.

This happens when a programs executable file has the
wrong context.
This happens when a third party software application
installed and it is given an inappropriate SELinux file
This was fixed with a chcon command and the
semanage commands.

chcon --type=traceroute_exec_t /usr/bin/nmap

ls Z /usr/bin/nmap
-rwxr-xr-x. root root system_u:object_r:traceroute_exec_t:s0 /usr/bin/nmap
semanage fcontext a t traceroute_exec_t /usr/bin/nmap

Wrong Object Context

The file(s) being accessed by the program has the wrong

object context.
This can happen for any number of reasons.
The installation of third party software may result in files
with wrong context because of inheritance from an upper
level directory.
Often, configuration files end up with the wrong context as
a result of how the system manager changes the
configuration file.
To repair the file, use the command

restorecon /path/to/file-name

Right Subject and Object Context but No Access

The program and the file have the correct contexts, but
the policy should allow some operation between the two
contexts, which is currently not allowed.
In this case, it will be necessary to modify the SELinux
First, consider looking thru the list of SELinux booleans
for one that is related to the service which is not working
using either getsebool or semanage.
Hmm. Whats an SELinux boolean?

SELinux Booleans

Minor modifications to SELinux policies can be made

without modifying and recompiling the policy source by
setting boolean values for optional features.
Such features include allowing users to share their home
directories under Samba or allowing Apache to serve files
from users home directories which would otherwise be
denied by the SELinux policy.
Originally, booleans were, well, booleans. They have
been extended beyond boolean values.
Get a listing of all the booleans:
getsebool a
semanage boolean l

SELinux Boolean Examples

Allow httpd to read users home directories but not

across a reboot:
setsebool httpd_enable_homedirs on
Allow httpd to read users home directories permanently:
setsebool P httpd_enable_homedirs on
Allow httpd to use an additional port:
semanage port a t http_port_t p tcp 8080

Audit2allow Policy Modules The Easy Way

Sometimes, it will be necessary to create and load a new

policy module.
An easy way to build a policy module is with the
audit2allow tool.
audit2allow takes input in the form of AVC denial
messages and generates syntactically correct Type
Enforcement rules which should be sufficient to prevent
the denials.
For example, to generate and display the rules which
would allow all denials in the audit log, do
audit2allow < /var/log/audit/audit.log

Audit2allow Examples

This not only might be overkill on the policy but also

difficult to scope out.
A better way to do is something like this:
ausearch i m AVC sv no ts recent | audit2allow

This will generate and display rules which should allow

kernel denials within the past five minutes.
To narrow the search down to particular program:
ausearch i m AVC sv no ts recent | grep prelude-manager |
Or make ausearch do the searching based on a type :
ausearch -i -m AVC -sv no ts recent se prelude_manager_t |

Building a Policy Profile

If you feel that this generated policy corrects the kernel

denials you are experiencing, you can use audit2allow to
create a policy module package suitable for loading into
the kernel policy.
A note about module naming conventions: Module names
must begin with a letter, optionally followed by letters,
numbers, "-", "_", ".
First generate the module source:
ausearch -i -m AVC -sv no ts recent se nrpe_t | audit2allow m
drwho-nrpe > drwho-nrpe.te

What a Policy Module Source File Looks Like

module drwho-nrpe 1.0;

require {
type nrpe_t;
type rpm_var_lib_t;
class dir search;

#============= nrpe_t ==============

allow nrpe_t rpm_var_lib_t:dir search;

Creating and Loading a Policy Package

Compile the policy source module into a binary

checkmodule -M -m o drwho-nrpe.mod drwho-nrpe.te
Create a SELinux policy module package from a binary
policy module:
semodule_package o drwho-nrpe.pp m drwho-nrpe.mod
Load the policy package into the kernel:
semodule install drwho-nrpe.pp
This looks suspiciously like compiling, linking and loading
a device driver.

Going From Permissive to Enforcing Mode

OK! Youve got all your problems with labeling and

contexts ironed out and youre ready to go to Enforcing
As with Linux theres more than one way to do anything. If
you want to make the transition to Enforcing Mode on a
provisional basis, do this as root:
setenforce enforcing
This will put the running kernel into Enforcing Mode. If
things dont seem to be running as well as you expected,
you can go back to Permissive Mode (and do more
debugging) by doing
setenforce permissive
Or use permissive domains

Permissive Domains

In permissive mode, SELinux performs all of the checks

and reports all of the AVC messages, but does not
enforce the denials.
A new capability in SELinux lets the administrator change
a single process (domain) to be permissive.
A permissive domain is a domain that performs the
SELinux access checks, however if SELinux policy would
have denied access, the kernel allows the access,
reports the AVC violation, and files get created with the
correct context.
semanage permissive -a nrpe_t
semanage permissive d nrpe_t
semanage permissive l

Permissive Domains Uses

They can be used for making a single process (domain)

run permissive to troubleshoot an issue without putting
the entire system at risk by making it permissive.
They allow an administrator to create policies for new
Previously, it was recommended that a minimal policy be
created, and then the entire machine put into permissive
mode, so that the application could run, but SELinux
denials still logged.
audit2allow could then be used to help write the policy.
This put the whole system at risk.
With permissive domains, only the domain in the new
policy can be marked permissive, without putting the
whole system at risk.

Indiana Jones and the Search for Unconfined

One last item to do before closing the case on going to

SELinux is checking for unconfined daemons.
This doesnt mean looking for daemons that are like
homeless people and have no shelter.
Daemons that SELinux has no policy for will inherit the
context of the parent process.
This is the init process and they get stuck with initrc_t as a
Two things can happen as result of this:
One is that it causes AVC denials
It could allow the daemon to have privileges it doesnt need.

The Magic Incantation for Unconfined Daemons

To check for unconfined daemons, do:

ps -eZ | egrep "initrc" | egrep -vw
"tr|ps|egrep|bash|awk" | tr ':' ' ' | awk { print $NF }
If you dont get any output from the above command list,
congratulations, you have no unconfined daemons!
You probably wont be so lucky, but youll know which
ones are still running unconfined and decide if they pose
an unacceptable security risk.
As an example, this is from a system used to scan for
network vulnerabilities:

Making Enforcing Mode a Way of Life

As it stands now, if the system youve been pouring

blood, sweat, tears into achieving Enforcing Mode were to
reboot, it would come up in Permissive Mode.
To make Enforcing Mode the modus operandi of the
system, edit /etc/selinux/config and change

SELinux Resources

If you want a one-stop-shopping center for SELinux

resources go to
And theres always the source

T-t-t-t-thats all, folks!

Gary Smith
Information System Security Officer, Molecular Science
Computing, EMSL, Pacific Northwest National
Richland, WA