5.2. Administrator Control of SELinux

5.2.1. View the Status of 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
...

5.2.2. Relabel a File System

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:

1. 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.

2. 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.

3. There is another method using the source policy. You want to avoid make relabel for the same reason you avoid using fixfiles.

5.2.3. Managing NFS Home Directories

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

	Caution
	Section 5.2.13 Specifying the Security Context of Entire File Systems explains how to mount a directory so that httpd is allowed to execute scripts. Doing that for user home directories gives Apache HTTP increased access to those directories. Remember that a mountpoint label is for the entire mounted file system.

Future versions of the SELinux policy address the functionality of NFS.

5.2.4. Grant Access to a Directory or a Tree

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[1]) 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 /.

5.2.5. Load a Policy

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.

5.2.6. Backup and Restore the System

Refer to the explanation in Section 5.1.4 Make Backups or Archives That Retain Security Contexts.

5.2.7. Enable or Disable Enforcement

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 SELinux Service Protection. Clicking on the triangle opens that menu, where you can choose to Disable SELinux protection for foo daemon. 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.

5.2.8. Change a Boolean Setting

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.

5.2.9. Enable or Disable SELinux

	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.

5.2.10. Change the Policy

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 Policy Type:. It is set to targeted and your custom policy appears there as policyname once the directory structure is in /etc/selinux. Click OK to accept the changes and reboot the system.

5.2.11. Troubleshoot User Problems With SELinux

This presents a brief methodology for troubleshooting problems that your users might have with SELinux.

5.2.12. Read an avc: denied Message

For information on how to read an AVC message, read Section 2.8.1 Understanding an avc: denied Message.

5.2.13. Specifying the Security Context of Entire File Systems

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.

5.2.14. Run a Command in a Specified Security Context

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

5.2.15. Useful Commands for Scripts

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:

5.2.16. Assume a New Role

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.

5.2.17. When to Reboot

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.