User:Jowr/selinuxrewrite

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

Gentoo supports SELinux installation both from scratch (via the requisite stage3 tarball) as well as by converting an existing non-SELinux system.

Conversion of an existing system
This process is relatively risk free, as Gentoo will happily run normally with SELinux userspace in an inconsistent state so long as the selinux filesystem in  is not mounted. It is, however, important that the steps be followed in this order to ensure that the system arrives in a stable state.

Reversion / removal is as simple as a profile change and a system rebuild.

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.

Setting mount point 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:

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.

Rebuild system
At this juncture, userspace needs to be rebuilt with SELinux support.

Rebuild your system with the above changes. Treat this like any other major system use flag / profile adjustment:

It is important that system userspace be in a consistent state for the next step.

Once the kernel and userspace are successfully built, reboot.

Fix filesystem labeling
The system will now have the required kernel and userspace support for SELinux.

This will ensure that every file on your system is properly labeled for SELinux.

Reboot again once this is done, as the running processes will not be running under the correct SELinux context.

Once this is done, you should see the following:

If that is indeed the case, proceed to Configure SELinux for further system tuning and configuration.

Installation from stage3
Using the SELinux stage3 with the same process as described in the handbook will leave you with a standard hardened gentoo installation with the system built for full SELinux support.

Setting mount point 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:

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.

With the above changes made, reboot the system.

Fix filesystem labeling
The system will now have the required kernel and userspace support for SELinux.

This will ensure that every file on your system is properly labeled for SELinux.

Reboot again once this is done, as the running processes will not be running under the correct SELinux context.

Once this is done, you should see the following:

Configure SELinux
In the second part of the SELinux installation, we will cover post-installation configuration of a SELinux system.

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.

make.conf settings
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.

Configuring the SELinux policy
The main SELinux configuration file is located at. It needs to be edited to set two important values:  and   if you wish to use a different policy or enforcement style.

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.

We will switch to enforcing later.

Set standard SELinux booleans
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.

You can view what SELinux booleans, their current and default states, and what they do with the following command:

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.

Enable the selinux_gentoo service
Gentoo provides an init script called which restores the contexts of dynamically created files and devices or pseudo file systems ( (optionally) and ) as those file systems cannot persist context changes across reboots.

The init script also supports booting in permissive mode first (for instance due to a custom initramfs that fails to work in enforcing mode) and switch to enforcing mode later.

Update the boot loader configuration with one or more of the following boot options:


 * nosetenforce if the system is booted with  and you do not want the init script to switch back to enforcing mode (if configured in ). If  file is configured to boot in permissive mode, this init script will not change this behavior.
 * norestorecon if you do not want to restore the contexts of.

Make administration easier
SELinux is difficult, and not just in the conceptual sense.

If you are willing to make some tradeoffs against system security, there are some changes that can be made that will smooth administration of a SELinux system.

Automatic root login to sysadm_r
As described previously, remote root logins require a role transition to sysadm_r in order to do administrative tasks. If you would like to have this transition automatically happen, it takes two simple steps:


 * Set up the SELinux boolean that allows this

The policy default is to not allow this behavior, however there's a boolean that controls this behavior.


 * Setup the root user context to allow the transition

SSH is what sets your user up with whatever role it is configured to use, as such it needs to be told to do this.

Open up  line.

No service or system restarts are necessary.

To test this, login as root again and you should be able to obtain the following:

Automatic init context transition for root
When a user wants to restart a service, the user needs both the ability to execute the init script in  as well as the ability to transition to the relevant SELinux initrc context.

It always ends up going like this:

If you do not wish to enter the root password every time you restart a service (Eg, you control access via SSH keys and keep the root password elsewhere) this is straight forward to setup.

Open. It will look like the following:

Uncomment out the pam_rootok.so line.

No service or system restarts are necessary.

To test this, login as root again and you should be able to obtain the following:

Summary
That's it. SELinux is now fully configured on the system. Although it will boot in permissive mode 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.

You can set the system to enforcing by editing, however it is strongly suggested that you do so on a temporary basis with before codifying this into the system configuration in case there are unexpected issues.