Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions




5.2. Administrator Control of SELinux

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.

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:


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

    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.


    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 \ /home


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.


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 \
   2:selinux-policy-targeted########################## [100%] 

mv /etc/selinux/targeted/policy/policy.18.rpmnew \

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

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

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


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

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.

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

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

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

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

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 \ /var/www/cgi


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:


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.


This command exits with a status of 0 if SELinux is enabled, and -256 if SELinux is disabled.

echo $?
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.

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.



LVM is the grouping of physical storage into virtual pools that are partitioned into logical volumes.

  Published under the terms of the GNU General Public License Design by Interspire