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.

SELinux stage3 tarballs are also available and supported - this is significantly easier than performing the steps below. The tarballs can be simply unpacked onto a target system, relabel the entire system, add the initial user to the administration SELinux user and reboot.

Performing a standard installation
Install Gentoo Linux according to the Gentoo Handbook installation instructions. It is recommended to use the hardened stage 3 tarballs. 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 targeted is 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.

Option 1: re-use the default gentoo-kernel-bin
The regular pre-built Gentoo dist-kernel "sys-kernel/gentoo-kernel-bin" already contains support for SELinux but it comes pre-DISABLED (as of 5.4.x).(via the option "SELinux runtime disable" = )

If you use this kernel-bin, it is NOT necessary to recompile in order to ENABLE it.

However, a kernel command-line parameter is REQUIRED at boot time (to undo the runtime disable) - (these can be set during grub):  is the new parameter, and can contain a list of other modules. Theoretically, you could append more modules to the  in a comma separated list, like "selinux,yama" (not part of this guide, but it is currently the only other LSM security module this default dist-kernel is built with).

is old and deprecated, and can only contain 1 entry, but still works.

Another parameter  is often mentioned instead, but doesn't actually take effect by itself, because the LSM parameter now takes precedence.

These parameters just ENABLE kernel support, after which, the  file will then take over and choose the mode of "enforcing/permissive/disabled" and type of "targeted/strict/mls/mcs". Enforcing mode can be set as a boot parameter with  or permissive mode set with

Those enforcing options will be relevant later in the guide, and dealt with, do not set them now

Option 2: recompiling kernel from gentoo-sources
The default Linux kernel sources also offer SELinux support, but need to be explicitly configured during compilation: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 to configure in :

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

If you must be able to enable/disable SELinux, the following settings allow to boot the kernel with option  to disable it:

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 base SELinux policy package. This package provides the SELinux configuration file which needs to be adjusted prior to building all other SELinux packages. As soon as is installed (it's a dependency of ), Portage will attempt to enable its SELinux support. However, as SELinux is currently not properly configured, it is necessary to disable this 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.

Relabel
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 command, substitute strict in the next command with targeted (or other policy store name) depending on the  value. If your system has more active mountpoints than the usual set of, list them too.

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 :

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

Sudo
can also be configured to transition from staff_u (or other) users to configured SELinux types/roles, for example:

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