SELinux/Installation

Getting a SELinux-powered Gentoo installation doesn't require weird actions. What is needed is to install Gentoo Linux with the correct profile, correct kernel configuration and some file system relabeling. It is seriously recommended to use SELinux together with other hardening improvements (such as PaX / grSecurity).

Installing Gentoo (Hardened)
This document assumes the reader starts with an existing Gentoo Linux system which needs to be converted to Gentoo with SELinux. It is possible to make the right decisions during a Gentoo installation to immediately start with a SELinux system. However, this article is focusing on a conversion of an existing system as that is the most common approach.

Performing a standard installation
Install Gentoo Linux according to the Gentoo Handbook installation instructions. It is recommended to use the hardened stage 3 tarballs and hardened-sources kernel instead of the standard ones, but standard stage installations are also supported for SELinux. Perform a full installation to the point that the system is booted into a (primitive) Gentoo base installation.

Choosing a SELinux policy type
Gentoo supports four policy types within SELinux: strict, targeted, mcs and mls.

The differentiation between strict and targeted is based upon the unconfined domain. When loaded, the processes on the system that are not specifically confined within a particular policy module will be part of the unconfined domains whose purpose is to allow most activities by default (rather than deny by default). As a result, processes that run inside unconfined domains have no restrictions apart from those already enforced by standard Linux security. Although running without the unconfined domains is considered more secure, it will also be more challenging for the administrator to make sure the system still functions properly as there are no policy modules for each and every application "out there".

Next to targeted and strict, administrators can opt for mcs to allow categorization of resources. This is useful on multi-tenant systems such as web servers, virtualization hosts, ... where multiple processes will be running, most of them in the same security domain, but in different categories. Note though that to take advantage of the additional category support, either the applications themselves (such as the web server or hypervisor tools) need to configure the SELinux categories (so they need to support SELinux) or the administrator will need to script around to start the individual instances with separate categories. Otherwise, mcs is just the same as targeted or strict.

Finally, Gentoo also provides mls to support a true multi-level security system. However, MLS is currently still considered experimental in Gentoo and as such not recommended.

In case of mcs or mls, the unconfined USE flag needs to be used to enable or disable unconfined domains in these policy types. The strict policy store does not use the USE flag at all (as it does not support unconfined domains at all) and the targeted policy store (which uses unconfined domains) requires the USE flag set.

Save the choice for the policy store in. That way, Portage will only install the policy modules for that SELinux policy store. By default, the SELinux profiles enable strict and targeted (with strict being the default active type).

Multiple stores can be defined, although only one store can be active at any point in time. This is handled through the SELinux configuration itself, which is covered later in the installation.

Setting file system contexts
If the location is a tmpfs-mounted file system, then it is necessary to tell the kernel that the root context of this location is   instead of , which is the default context assigned to tmpfs-mounted file systems.

To configure the mount, edit the  file:

Next, set the next line in to configure the context for the  location:

Change the Gentoo profile
Switch the Gentoo profile to the right SELinux profile (for instance, ).

Starting from the profile change, Portage will warn after every installation that it was "Unable to set SELinux security labels". This is to be expected, because the tools and capabilities that Portage requires to set the security labels aren't available yet. This warning will vanish the moment the SELinux installation is completed.

Don't update the system yet - a couple of packages need to be installed first in a particular order that Portage isn't aware of.

Updating make.conf
Take a look at the following SELinux related USE flags and decide which ones to enable or disable.

Update the USE variable in or in an appropriate  location for the  package.

Installing a SELinux kernel
Although the default Linux kernels offer SELinux support, it is recommended to use the package as it offers more hardening features alongside SELinux.

Next, reconfigure the kernel with the appropriate security settings. This includes, but is not limited to


 * Support for extended attributes in the various file systems
 * Support system-call auditing
 * Support for SELinux

Below a quick overview of the recommended settings can be found.

Do not forget to set the Default security module to SELinux. Otherwise, the  boot parameter has to be set in the bootloader configuration.

It is recommended to use PaX as well. More information on PaX within Gentoo Hardened can be found in the Hardened Gentoo PaX Quickstart Guide.

Build and install the new Linux kernel and its modules.

Reboot
With the above changes made, reboot the system.

Configure SELinux
In the second part of the SELinux installation, we cover the installation of the proper utilities, relabel the entire file system and configure the policy.

Installing policies and utilities, part one
First, install the and  packages. Although these will be pulled in as dependencies of the SELinux policy packages themselves, a one-time installation is needed in advance.

Next, install the base SELinux policy package. This package provides the SELinux configuration file which needs to be adjusted prior to building all other SELinux packages. As the package is deployed, Portage would attempt to enable its SELinux support. However, as SELinux is currently not properly configured, it is necessary to disable its SELinux support through :

Configuring the SELinux policy
The main SELinux configuration file is now at. It needs to be edited to set two important values:  and.

The  variable defines how SELinux should behave:
 * enforcing will enable and enforce policies. This is the target at the end, but we need to start in permissive mode first to make sure everything would work as expected.
 * permissive will enable policies, but not enforce them. Any violation is reported but not denied. This is where most users should start from as it will not impact the system, yet allow users to get acquainted with SELinux - and validate the warnings to see if the system can be switched towards enforcing or not later.
 * disabled will completely disable the policies. As this will not show any violations as well, it is not recommended.

The  variable selects the SELinux policy store to load. Most development is done using the strict policy store (as it provides full confinement), although the others are supported as well.

Make sure that the  variable is set to permissive right now. We will switch to enforcing later.

Installing policies and utilities, part two
Now continue with the installation of the SELinux policies. Rebuild the package if   is changed to something else than strict, and then install the core SELinux policies through the  package. This package contains the core SELinux policies needed to get the system up and running using SELinux. As Portage will try to label and reload policies we need to temporarily disable SELinux support again (as Portage wouldn't be able to label anything as it doesn't understand it yet).

Now it is finally time to rebuild all packages affected by the profile change. Don't forget to use  or   afterwards as some changes to configuration files will need to be made. This operation will also pull in all SELinux policy packages needed for the various components already installed on the system.

Reboot and relabel
First reboot the system so that the installed policies are loaded.

Next relabel all devices and openrc related files. This will apply the correct security contexts (labels) onto the necessary files. We start by bind-mounting onto. This will allow us to relabel the mount points themselves rather than the mounted file systems that are already mounted on the main file system.

In the following commands, substitute strict in the next command with targeted (or other policy store name) depending on the  value. Also, use instead of  if the system is a 32-bit system.

If the system uses a swapfile rather than a swap partition, label it accordingly:

Now relabel the entire file system. The next command will apply the correct security context onto the files on the entire file system, based on the security context information provided by the SELinux policy modules installed.

If a SELinux policy module for a package is installed after that particular package, then  needs to be run for that package to make sure that the security contexts for its files are set correctly. For instance, if would be installed manually (due to a missing dependency) after installing :

Reboot and set SELinux booleans
Reboot the system so that the newly applied file contexts are used. Log on and, if Gentoo is installed using the hardened sources (as is recommended), enable the SSP SELinux boolean.

SELinux booleans enable (or disable) SELinux policy rules based on the boolean value. In this case, the boolean allows every domain read access to the device.

Define the administrator accounts
If the  variable is set to strict, then it is necessary to map the account(s) used to manage the system (those that need access to Portage) to the staff_u SELinux user. If not, none of the accounts will be able to succesfully manage the system (except for root, but then the administrator will need to login as root directly and not through  or  .) By default, users are mapped to the user_u SELinux user who doesn't have the appropriate rights (nor access to the appropriate roles) to manage a system. Accounts that are mapped to staff_u can, but might need to switch roles from staff_r to sysadm_r before they are granted the appropriate privileges.

In the following example, we map the john Linux account to the staff_u SELinux user:

When system administration tasks need to be executed, the user will need to switch the role to sysadm_r. For this, the  command can be used.

In a targeted policy, the users will be of type unconfined_t and will already have the necessary privileges to perform system administrative tasks.

Supporting service administration
By default, the Gentoo Hardened SELinux policies will allow the sysadm_t domain access to all services. However, some of these services have policies that allow them to be assigned to individual, non-root users. This requires the user to be granted the system_r role (meaning the user can, under certain circumstances, have his role change towards the system role).

It is therefor recommended to grant the system_r role to the administrative SELinux users that are going to administer the system. These are most likely the root and staff_u SELinux user.

Summary
That's it. SELinux is now fully configured on the system. Although it will boot in permissive mode (most likely) right now, everything is now in place to validate if SELinux will further prevent applications from working or not. If, after booting and logging in, the  command shows the proper context, then the system is most likely ready to be switched into enforcing mode (by editing ).