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 SELinux.
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:
/usr/bin/sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 18
Policy from config file:targeted
Policy booleans:
allow_ypbind active
dhcpd_disable_trans active
httpd_disable_trans inactive
httpd_enable_cgi active
... |
The -v option adds on a report about the security
contexts of a series of files that are specified in
/etc/sestatus.conf:
Process contexts:
Current context: root:system_r:unconfined_t
Init context: user_u:system_r:unconfined_t
/sbin/mingetty user_u:system_r:unconfined_t
/usr/sbin/sshd user_u:system_r:unconfined_t
File contexts:
Controlling term: root:object_r:devpts_t
/etc/passwd system_u:object_r:etc_t
/etc/shadow system_u:object_r:shadow_t
/bin/bash system_u:object_r:shell_exec_t
/bin/login system_u:object_r:bin_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.
touch /.autorelabel
reboot |
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 difficult.
It is possible to relabel a live file system using
fixfiles, or to relabel based on the RPM
database:
fixfiles relabel
fixfiles -R packagename restore |
Using the ability of fixfiles to restore contexts
from packages is safer and quicker.
 | Caution |
|---|
| | 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 execute.
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 \
fileserver.example.com:/shared/homes/ /home |
Future versions of the SELinux policy address the functionality of
NFS.
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 Policy.
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 Policy.
 | Note |
|---|
| | 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 production
machines.
|
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 policy upgrade.
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 \
/etc/selinux/targeted/policy/policy.18.rpmnew
2:selinux-policy-targeted########################## [100%]
mv /etc/selinux/targeted/policy/policy.18.rpmnew \
/etc/selinux/targeted/policy/policy.18 |
Otherwise, install the new policy source and load a new policy.
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 Policy.
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
policy.
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:
setenforce 1
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:
getsebool named_disable_trans
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
getsebool named_disable_trans
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 bidirectionally.
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 load.
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
httpd_disable_trans=1
mysqld_disable_trans=1
ntpd_disable_trans=1
# You can pass any number of boolean_value=0|1
setsebool -P httpd_disable_trans=0 mysqld_disable_trans=0 \
ntpd_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.
Using system-config-securitylevel, 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.
 | Important |
|---|
| | 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 boot.
# 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.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted |
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 system.
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 the system.
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 at https://bugzilla.redhat.com.
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 Contexts
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
httpd_sys_content_t:
mount -t nfs -o context=system_u:object_r:httpd_sys_content_t \
server1.example.com:/shared/scripts /var/www/cgi |
 | Tip |
|---|
| | 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 occur.
|
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 mislabeled content.
# 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:
- getenforce
This command returns the enforcing status of SELinux.
- setenforce [ Enforcing |
Permissive |
1 | 0
]
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 violations.
- selinuxenabled
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
determined.
- 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
setenforce 0.
