Administrators can expect to do most of the same things that
users do in Section 5.1
End User Control of SELinux, plus a number of additional
tasks that are usually done only at the root level. Using the
targeted policy makes tasks measurably easier for the
administrator. For example, there is no need to consider adding,
editing, or deleting Linux users from the SELinux users, nor do you
need to consider roles.
This section covers the types of tasks that an administrator
needs to do to maintain Red Hat Enterprise Linux running
The command sestatus provides a
configurable view into the status of SELinux. By itself, the
command shows the enabled status, selinuxfs mount point, current
enforcing mode and what that is set to in the configuration file,
and the policy name and its version number. Following that are a
list of all the policy Booleans and their status:
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 18
Policy from config file:targeted
The -v option adds on a report about the
security contexts of a series of files that are specified in
Current context: root:system_r:unconfined_t
Init context: user_u:system_r:unconfined_t
Controlling term: root:object_r:devpts_t
You may never need to relabel an entire file system. This
usually occurs only when labeling a file system for SELinux for the
first time, or when switching between different kinds of policy,
such as going from the targeted to the strict policy.
There is one good method for relabeling the file system. You may
also hear about two other methods, both of which are not recommended. Here they are in order:
The best and cleanest method to relabel is to let init do it for you on boot.
By allowing the relabeling to occur early in the reboot process,
you ensure that applications have the right labels when they are
started and that they are started in the right order. If you
relabel a live file system without rebooting, you may have
processes running under the incorrect context. Making sure all the
daemons are restarted and running in the right context can be
It is possible to relabel a live file system using fixfiles, or to relabel based on the RPM
fixfiles -R packagename restore
Using the ability of fixfiles to
restore contexts from packages is safer and quicker.
Running fixfiles on the whole file
system without rebooting may make the system unstable.
If the relabeling operation applies a new policy that is
different from the policy that was in place when the system booted,
existing processes may be running in incorrect and insecure
domains. For example, a process could be in a domain that is not an
allowed transition for that process in the new policy, granting
unexpected permissions to that process alone.
In addition, one of the options to fixfiles
relabel prompts for approval to empty /tmp/ because it is not possible to reliably
relabel /tmp/. Since fixfiles is run as root, temporary files that
applications are relying upon are erased. This could make the
system unstable or behave unexpectedly.
There is another method using the source policy. You want to
avoid make relabel for the same reason you
avoid using fixfiles.
In Red Hat Enterprise Linux 4 most targeted daemons do not
interact with user data and are not affected by NFS-mounted home
directories. One exception is Apache HTTP. For example, CGI scripts
that are on the mounted file system have the nfs_t type, which is not a type
httpd_t is allowed to
If you are having problems with the default type of nfs_t, try mounting the home directories
with a different context:
mount -t nfs -o context=user_u:object_r:user_home_dir_t \
Future versions of the SELinux policy address the functionality
Just as with regular Linux DAC permissions, a targeted daemon
must have SELinux permissions to be able to descend the directory
tree from the root. This does not mean that a directory and its
contents need to have the same type. There are many types, such as
root_t, tmp_t, and usr_t that grant read access for a
directory. These are good types to use if you have a directory with
no secret information you want to be widely readable. It might also
make a good directory type for a parent directory of more secured
directories with different contexts.
If you are working with an avc:
denied message, there are some common problems that arise
with directory traversal. For example, many programs do an
equivalent command to ls -l / that is not
necessary to their operation but generates a denial message in the
logs. For this you need to create a dontaudit rule in your local.te file. Read more about this in Chapter 8 Customizing and Writing
When you are interpreting the AVC denial message, you might get
misled by the path=/ component.
This path is not related to the label for the root file system,
/. It is actually relative to the root of
the file system on the device node. For example, if your /var/ directory is located on an LVM (Logical Volume
Management) device, /dev/dm-0, the device node is identified in the
message as dev=dm-0. When you
see path=/ in this example,
that is the top level of the LVM device dm-0, not neccesarily the same as the root file
system designation /.
There are two routes to loading a policy. One is to install a
binary policy from a package or copy a custom binary policy into
$SELINUX_POLICY/. The other is to use the policy source and load
eithr the supported or a custom policy. For information on this
second option, read Chapter 7
Compiling SELinux Policy and Chapter 8 Customizing and Writing
It is not common to install the policy sources unless you need
to work with them directly. On a normal production server, you are
not likely to have policy source installed even if you are running
a customized policy. You develop that policy on a separate machine
that has the source installed, and deploy it as a binary policy to
You can upgrade the package using up2date or rpm. If you are
managing your own custom policy, either package it or copy the
binary policy file policy.XY to the target machine.
However, if you have the policy source package installed
and you have loaded the policy from source,
such as running make load or make reload in the $SELINUX_SRC/ directory, then installing binary
policy packages is slightly more complicated.
The install scripts packaged with the policy check to see if you
have the policy source package installed and if you loaded policy
from source. It does this by comparing the file at $SELINUX_POLICY/policy.XY with the binary policy from the
package. If they are different, the new binary policy is created
with an .rpmnew file extension. This way
you are protected from having your customizations overwritten by a
If you want to use the binary policy, move the replacement over
the older version:
rpm -Uvh /tmp/selinux-policy-targeted-*
Preparing... ########################## [100%]
1:selinux-policy-targeted########################## [ 50%]
warning: /etc/selinux/targeted/policy/policy.18 created as \
mv /etc/selinux/targeted/policy/policy.18.rpmnew \
Otherwise, install the new policy source and load a new
This situation occurs as a protection against an updated policy
package overwriting a custom binary policy. Future policy packages
will address this challenge further.
If you want to deploy a custom binary policy, read Section 8.4 Deploying Customized Binary
You can enable and disable SELinux enforcement in runtime or
configure it for system boot, using the command line or GUI. There
are three modes for SELinux to be in: disabled, meaning not enabled in the kernel;
permissive, meaning SELinux is running and
logging but not controlling permissions; enforcing, meaning SELinux is running and enforcing
To toggle enforcement during runtime, use the setenforce [ 0 | 1 ] command. The 0 option turns enforcement off, the 1 option turns it on.
# sestatus informs you of the two permission mode statuses,
# the current mode in runtime and the mode from the config
# file referenced during boot:
sestatus | grep -i mode
Current mode: permissive
Mode from config file: permissive
# Changing the runtime enforcement doesn't effect the
# boot time configuration:
sestatus | grep -i mode
Current mode: enforcing
Mode from config file: permissive
However, you may be looking for something more subtle. For
example, if you are having trouble with named and SELinux, you can turn off enforcing for
just that daemon:
# This gets the current status of the Boolean:
named_disable_trans --> inactive
# This sets the runtime value only. To flush the pending
# value to disk use the -P option.
setsebool named_disable_trans 1
named_disable_trans --> active
You can configure all of these settings using system-config-securitylevel. The same
configuration files are used, so changes show up
To set SELinux to enforcing, choose the SELinux tab and select the checkboxes next to
Enabled (Modification Requires Reboot) and
Enforcing. After clicking OK, you need to reboot if you have just enabled
SELinux from disabled.
To set SELinux to permissive mode, deselect the checkbox next to
Enforcing. The mode changes when you click
the OK button.
To disable SELinux enforcement over a targeted daemon, you are
setting a Boolean value so that SELinux does not transition the
program to the targeted domain.
In the SELinux tab, under the Modify SELinux Policy section, there is a menu
. Clicking on the
triangle opens that menu, where you can choose to . Clicking the OK button makes the change take effect.
If you are interested in controlling these configurables with
scripts, the tools setenforce(1),
getenforce(1), and selinuxenabled(1) may be useful to you.
Booleans are reconfigurable in runtime, and you can choose to
write the setting to the configuration files for the next policy
The reliable command line method is to use setsebool:
setsebool httpd_enable_homedirs 1
By itself, setsebool only changes the
current state of the Booleans. The -P
option writes all pending changes to the file /etc/selinux/targeted/booleans. In this example you
are enabling policy enforcement for a list of daemons:
# Any *_disable_trans set to 1 are invoking the conditional that
# prevents the process from transitioning to the domain on exec:
grep disable /etc/selinux/targeted/booleans | grep 1
# You can pass any number of boolean_value=0|1
setsebool -P httpd_disable_trans=0 mysqld_disable_trans=0 \
grep disable booleans | grep 1
If you already know the setting of a Boolean, you can use
togglesebool boolean_name to flip the setting.
Boolean control is in the SELinux tab,
under the Modify SELinux Policy section.
Each Boolean has a checkbox in the menu. Settings take effect when
you click OK.
Changes you make to files while SELinux is disabled may give
them an unexpected security label, and new files do not have a
label. You may need to relabel part or all of the file system after
enabling SELinux again.
From the command line, you can edit the file /etc/sysconfig/selinux. You'll notice the file is a
symlink to /etc/selinux/config. The
configuration file is self-explanatory. Changing the value of
SELINUX= or SELINUXTYPE= changes the state of SELinux
and the name of the policy to be used upon the next system
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
Using system-config-securitylevel in
the SELinux tab, uncheck Enabled (Modification Requires Reboot), click
OK to accept the changes, then reboot.
This immediately changes the setting in /etc/sysconfig/selinux.
If you are interested in customizing the policy, read Chapter 8 Customizing and Writing
Policy. If you have a different policy that you wish to
load on your system, such as a strict or other specialized policy,
you only need to set SELINUXTYPE=policyname, where policyname is the same as the directory
/etc/selinux/policyname. This presumes you have the
custom policy installed, which is also covered in Chapter 8 Customizing and Writing
Policy, as well as troubleshooting steps to get a custom
policy working on a different system. After changing the SELINUXTYPE parameter, you want to
touch /.autorelabel and reboot the
To use system-config-securitylevel to
switch the policy, in the SELinux tab there
is a drop-down menu . It is set
to and your custom policy
appears there as once the
directory structure is in /etc/selinux.
Click OK to accept the changes and reboot
This presents a brief methodology for troubleshooting problems
that your users might have with SELinux.
Deciphering the denial message is the first step in
troubleshooting. Read Section 2.8.1
Understanding an avc: denied
Message for how to do that. You might want to use seaudit if there are a large number of AVC audit
messages. You can read more about seaudit in Section 6.2 Using seaudit for Audit Log Analysis. Here are
the questions you want answered:
What is the process that is being blocked? You can find its
context from the scontext=
portion of the message.
What is the target object? The path= and the tclass= tell you where and what the object
is. You get it's context from tcontext=. You may need the ino= to find an object if it's path is not
evident. This may happen because SELinux reports the path as
relative to the device node dev=.
What is the permission attempted?
Knowing these essential who, what, where, and how questions
should help you in determining the why. At this point it may be
obvious, such as the tcontext=
being set to a context the process clearly should not be writing
to. This may point back to troubles in the application or script,
or troubles in the type for the subject or object.
If you need to analyze the policy further, you can try using the
source and target contexts as search parameters with the apol tool. You can learn more about how to do
this in Section 6.3 Using
apol for Policy Analysis.
If you think the interaction should be allowed and represents a
policy bug, you can insert policy to allow it. Read Chapter 8 Customizing and Writing
Policy for information on doing this, and file a bug report
Using the mount -o context= command you
can set a single context for an entire file system. This might be
an already mounted file system that supports xattrs, or a network
file system that obtains a genfs label such as cifs_t or nfs_t. This is explained in Section 2.4 File System Security
For example, if you need to have Apache HTTP read from a mounted
directory or loopback file system, you need to set the type to
mount -t nfs -o context=system_u:object_r:httpd_sys_content_t \
When troubleshooting httpd and SELinux
problems, reduce the complexity of your situation. For example, if
you have the file system mounted at /mnt
and then symlinked to /var/www/html/foo,
you have two security contexts to be concerned with. Since one is
of the object class file and
the other lnk_file, they are
treated differently by the policy and unexpected behavior may
This is useful for scripting or testing policy, although it can
be tricky to do correctly. The runcon
command lets you specify the domain that you want to run a program
or script in. For example, you could runcon -t
httpd_t /path/to/script for a script that tested for
# The arguments that appear after the command are considered to
# be part of the command being run
runcon -t httpd_t ~/bin/contexttest -ARG1 -ARG2
# You can also specify the entire context
runcon user_u:system_r:httpd_t ~/bin/contexttest
You many need access to SELinux information and capabilities for
scripts you write in administrating your system. This is a list of
useful commands introduced with SELinux:
This command returns the enforcing status of SELinux.
- setenforce [ Enforcing | Permissive | 1 |
This command controls the enforcing mode of SELinux. The option
1 or Enforcing
tells SELinux to begin enforcing. The option 0 or Permissive tells SELinux
to stop enforcing, although it continues logging access
This command exits with a status of 0 if SELinux is enabled, and -256 if SELinux is disabled.
- getsebool [-a] [boolean_name]
This command shows the status of all (-a) or a specific Boolean can be
- setsebool [-P] boolean_name value |
bool1=val1 bool2=val2 ...
This command sets one or more Boolean values. The option
-P commits all pending Boolean changes to
the configuration file at /etc/selinux/targeted/booleans.
- togglesebool boolean ...
This command toggles the setting of one or more Booleans.
Whatever the setting was, it is now switched to the opposite. This
effects Boolean settings in memory only, and does not change the
Boolean setting in /etc/selinux/targeted/booleans.
This program lets you run a new shell with the specified type
and/or role. Switching roles does not have the same meaning in the
targeted policy as it does in a strict policy, so that function is
largely ignored. It may be useful to you to assume a new type for
testing, validation, and development purposes:
newrole -r role_r -t type_t [-- [ARGS]...]
The ARGS following the
-- are passed directly to the
shell. The shell chosen is based on the user's entry in /etc/passwd.
Your primary reason for rebooting with SELinux is to get your
file system properly labeled using the /.autorelabel file. Another reason might be to
completely enable or disable SELinux.
Otherwise, you can safely make SELinux permissive by using