Security Enhanced Linux

What is SELinux?

Security Enhanced Linux (SELinux) is a technology that extends the basic access control mechanisms of the Unix model (file ownership, file access permission modes and a general exception for "root") with an additional layer of so-called mandatory access controls controlled by detailed access policies.

In most Linux distributions that include SELinux, potentially vulnerable daemons such as web servers are confined by policy allowing them only the minimal access required to perform their functions. This means that even a subverted daemon is limited in the amount of damage that it can do to the system.

SELinux is shipped with many Linux distributions, including Red Hat Enterprise Linux, CentOS, Fedora and Debian Etch. In RHEL, CentOS and Fedora distributions, it is enabled in an "enforcing" mode by default.

SELinux and Shibboleth

As SELinux becomes more popular, it is obviously important that the Shibboleth SP be able to work properly in an SELinux environment. To do this, SELinux policy needs to be added to the system's policy database both to correctly confine the shibd daemon and to allow appropriate communication between that daemon and the web server.

Back when SELinux and Shibboleth were both much younger, Derek Atkins wrote some SELinux policy that worked with the Shibboleth of the day and with the SELinux of the day. This has been shipped as a separate Shibboleth SELinux RPM alongside the main SP RPM since that time.

Unfortunately, Derek's policy no longer works, primarily because of dramatic changes in SELinux as it matured. In particular, distributions have moved from using policy based on a framework confusingly known as the "example policy" to one based on the equally unhelpfully named "reference policy". Installation of policy has also changed radically, from being based around scripted modification of the system's policy source files to one based on separately compiled policy modules.

Because Red Hat Enterprise Linux 5, CentOS 5, Fedora Core 6, Fedora 7, and Debian Etch are all based around the modular reference policy, Derek's policy is no longer installable on those systems. The simplest way to run Shibboleth on such systems at present is to disable SELinux altogether, or to set it to a "permissive" mode in which policy violations are reported but not enforced. This is obviously far from ideal.

Current Status and New Policy Development

In order to reduce confusion, we are no longer building SELinux RPMs for supported systems for Shibboleth 1.3 or Shibboleth 2.0.

A new policy module has been developed for Shibboleth 1.3. This has been tested to some extent under Red Hat Enterprise Linux 5 (CentOS 5) and more testers are now required. Please contact Ian Young if you would like to assist with this.

For the immediate future, the new policy modules will be kept separate from the main development stream. It is likely that the new SELinux policy will be integrated into the Shibboleth 2.0 packages at some point. This is less likely to be the case for Shibboleth 1.3 as development effort moves to Shibboleth 2.0.

Installing Experimental Policy Modules

This section provides instructions for people testing the new policy modules.

Preparing Your System

SELinux may be in one of three states on your system:

disabled
enabled and permissive
enabled and enforcing

Before installing the new policy modules, you should get Shibboleth and your application working with SELinux enabled but permissive.

You can find out whether SELinux is enabled and, if so, which mode it is running in using the sestatus command.

[root@shib selinux]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 21
Policy from config file:        targeted

If your SELinux status is disabled, you must enable SELinux. In RHEL5, this can be done with the system-config-securitylevel GUI command. Under the SELinux tab, change the SELinux setting from "Disabled" to "Permissive" and select OK.

Note that if SELinux was previously disabled, it is likely that most of your files have incorrect (or no) security context labels. To fix this, system-config-securitylevel should ask to reboot your system so that the file system can be relabelled.

If SELinux is currently in enforcing mode, it is probably simplest to use system-config-securitylevel to change to permissive mode initially.

Once you have installed the policy files and verified that things appear to be working, you can transition the system to enforcing mode for production use.

With SELinux enabled in permissive mode, get your Shibboleth SP and your application working. Once it is working, proceed to policy installation.

Installing SELinux Policy

The new SELinux policy comes distributed in a file with a name like shibd-selinux-x.x.x.y.tar.gz, where x.x.x is a Shibboleth version number and y is a build number for the file. Unpack this file to produce a directory called shibd-selinux-x.x.x.y. Inside you should find:

Source files:
- shibd.fc is the file context policy source file
- shibd.te is the type enforcement policy source file
- shibd.if is the policy interface source file
- Makefile would allow you to rebuild the policy module if you had all the appropriate development packages installed; you can ignore it
Deliverables:
- relabel is used to apply appropriate security contexts to critical files
- shibd is a replacement service control file for the daemon
- shibd.pp is the compiled policy module

To install policy, proceed as follows:

# service shibd stop
# service httpd stop
# cp shibd /etc/init.d/shibd
# chmod +x /etc/init.d/shibd
# semodule -i shibd.pp
# ./relabel

Once your policy is installed, you can start testing.

Testing Experimental Policy

The way you will find out if the experimental policy is failing in your system is by SELinux denial messages in the /var/log/messages file. It's worth opening a window to monitor this:

# tail -f /var/log/messages

Now, restart the Shibboleth daemon and your web server:

# service shibd start
# service httpd start

At this point, you should be able to access your application without any denial messages being issued. If you do see problems, please report them in the Internet2 JIRA system on the C++ SP project, specifying the SELinux component.