The Shibboleth V1 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only.
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 fileshibd.te
is the type enforcement policy source fileshibd.if
is the policy interface source fileMakefile
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 filesshibd
is a replacement service control file for the daemonshibd.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.