Basics of SELinux

If you are using a distribution that comes bundled with SELinux (such as Fedora), here are some recommendation of how to make the best use of it to maximize your workstation security.

Checklist

• Make sure SELinux is enforcing on your workstation (ESSENTIAL)
• Never blindly run audit2allow -M, always check (ESSENTIAL)
• Never setenforce 0 (NICE)
• Switch your account to SELinux user staff_u (NICE)

Considerations

SELinux is a Mandatory Access Controls (MAC) extension to core POSIX permissions functionality. It is mature, robust, and has come a long way since its initial roll-out. Regardless, many sysadmins to this day repeat the outdated mantra of "just turn it off."

That being said, SELinux will have limited security benefits on the workstation, as most applications you will be running as a user are going to be running unconfined. It does provide enough net benefit to warrant leaving it on, as it will likely help prevent an attacker from escalating privileges to gain root-level access via a vulnerable daemon service.

Our recommendation is to leave it on and enforcing.

Never setenforce 0

It's tempting to use setenforce 0 to flip SELinux into permissive mode on a temporary basis, but you should avoid doing that. This essentially turns off SELinux for the entire system, while what you really want is to troubleshoot a particular application or daemon.

Instead of setenforce 0 you should be using semanage permissive -a [somedomain_t] to put only that domain into permissive mode. First, find out which domain is causing troubles by running ausearch:

ausearch -ts recent -m avc

and then look for scontext= (source SELinux context) line, like so:

scontext=staff_u:staff_r:gpg_pinentry_t:s0-s0:c0.c1023

This tells you that the domain being denied is gpg_pinentry_t, so if you want to troubleshoot the application, you should add it to permissive domains:

semanage permissive -a gpg_pinentry_t

This will allow you to use the application and collect the rest of the AVCs, which you can then use in conjunction with audit2allow to write a local policy. Once that is done and you see no new AVC denials, you can remove that domain from permissive by running:

semanage permissive -d gpg_pinentry_t

Use your workstation as SELinux role staff_r

SELinux comes with a native implementation of roles that prohibit or grant certain privileges based on the role associated with the user account. As an administrator, you should be using the staff_r role, which will restrict access to many configuration and other security-sensitive files, unless you first perform sudo.

By default, accounts are created as unconfined_r and most applications you execute will run unconfined, without any (or with only very few) SELinux constraints. To switch your account to the staff_r role, run the following command:

usermod -Z staff_u [username]

You should log out and log back in to enable the new role, at which point if you run id -Z, you'll see:

staff_u:staff_r:staff_t:s0-s0:c0.c1023

When performing sudo, you should remember to add an extra flag to tell SELinux to transition to the "sysadmin" role. The command you want is:

sudo -i -r sysadm_r

At which point id -Z will show:

staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

WARNING: you should be comfortable using ausearch and audit2allow before you make this switch, as it's possible some of your applications will no longer work when you're running as role staff_r. At the time of writing, the following popular applications are known to not work under staff_r without policy tweaks:

• Chrome/Chromium
• Skype
• VirtualBox

To switch back to unconfined_r, run the following command:

usermod -Z unconfined_u [username]

and then log out and back in to get back into the comfort zone.