SELinux For Dummies - LinuxFest Northwest 2015

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 we’ve 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.
It’s called a file context when it is associated with a file.
If it’s associated with a process, it’s 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.
I’m 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 file’s 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, you’ll be presented with an option to enable it on
the first boot after installation and “Bob’s 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
Here’s 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 program’s 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. What’s 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! You’ve got all your problems with labeling and
contexts ironed out and you’re ready to go to Enforcing
As with Linux there’s 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 don’t 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 doesn’t 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 doesn’t 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 don’t get any output from the above command list,
congratulations, you have no unconfined daemons!
You probably won’t be so lucky, but you’ll 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 you’ve 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 there’s always the source
T-t-t-t-that’s all, folks!
Gary Smith
Information System Security Officer, Molecular Science
Computing, EMSL, Pacific Northwest National
Richland, WA
[email protected]

similar documents