Red Hat Enterprise Linux 8 introduced a number of changes from previous versions of the operating system. When it comes to server hardening, one of the most notable changes is the introduction of authselect, the replacement for the old authconfig tool. The authselect utility manages PAM and NSS by creating profiles and allowing administrators to select the active profile. In contrast, authconfig would directly modify system files, including Samba and OpenLDAP configuration files.

One of the best features of authselect is the ability to create custom profiles. This allows administrators to essentially fork one of the default profiles (sssd, winbind, nss), make their own modifications to it, and select it. Once the profile is selected, /etc/nsswitch.conf and several PAM configuration files in /etc/pam.d are modified to point at the active profile in /etc/authselect. This allows for a clearer distinction between system- and user-provided configurations. Custom authselect profiles are also very useful for implementing security hardening. The CIS benchmark for RHEL 8 has several items that either directly involve authselect, or are best implemented using custom authselect profile. In the rest of this post, I’ll demonstrate how I’m using a custom profile to meet CIS benchmark compliance.

Section 5.3 of the RHEL 8 CIS benchmark is very straightforward: the requirement is to configure a custom authselect profile. I’ll use the included SSSD profile as a base, since it’s what I use in my environment for Active Directory integration:

authselect create-profile hardened sssd

This will create the new profile under /etc/authselect/custom/hardened. If you take a look in that directory, you’ll see several configuration files. The most relevant ones here are nsswitch.conf, which sets up name switching, and the system-auth and password-auth files, which are PAM configuration files for managing authentication. There’s also several other PAM files in that directory, but we’ll be ignoring those for now. If we inspect the system-auth file, we’ll see something a little different than a standard PAM file:

auth required pam_faillock.so preauth silent deny=4 unlock_time=1200 {include if "with-faillock"}

This is an example of an authselect feature. When you select a profile, you can pass in a list of features to enable different options in the profile. In this example, if you select the profile and provide the with-faillock argument, the pam_faillock.so module will be included, and will be configured as above. If you want to see all of the available features for a profile, run authselect list-features profile-name.

Moving on to CIS benchmark requirements, we can meet compliance with all three items in section 5.3 just by creating a custom authselect profile, and enabling the with-faillock feature to ensure that local user accounts are locked out after repeated failed authentication attempts. Items 5.4.1, 5.4.2, and 5.4.4 in the benchmark are either handled outside of PAM, or are covered by the defaults present in our custom profile. That leaves us with one more item to configure: 5.4.3 - Ensure password reuse is limited. For this, we’ll need to modify some of the PAM files in our custom profile directly:

for file in password-auth system-auth; do
    sed -i -e "/^password\s*sufficient\s*pam_unix.so/ s/$/ remember=5/" /etc/authselect/custom/hardened/$file
    sed -i -e "/^password\s*requisite\s*pam_pwquality.so/ s/$/ enforce_for_root retry=3 remember=5/" /etc/authselect/custom/hardened/$file
done

The above changes configure PAM to remember the last five passwords for each local user. It also enforces password qualtiy requirements for the root user. With that done, we have a CIS-compliant custom profile and PAM stack. Now all that’s left to do is select the profile:

authselect select custom/hardened with-faillock without-nullok

The without-nullok feature prevents users from creating null passwords. We can verify that our profile is active by running authselect current. This also lists the enabled features for the active profile. There’s a lot of features that are worth looking into, especially for the sssd profile (and our custom profile based on it). If you’re using Active Directory or IPA for user management, you’ll also want to enable the with-mkhomedir feature, so that users’ home directories are created on their initial login.