Some PAM rules `pass` during remediation, but then they `fail` during final scan

[mildas]

Description of problem:

During hardened kickstart installation, set_password_hashing_algorithm_passwordauth, set_password_hashing_algorithm_systemauth, and accounts_password_pam_retry PAM rules pass. After installation when scanning, the rules fail because expected object has not been found. For example:

set_password_hashing_algorithm_passwordauth - final scan

check /etc/pam.d/password-auth for correct settings  oval:ssg-test_pam_unix_passwordauth_sha512:tst:1  false

No items have been found conforming to the following objects:

Object oval:ssg-object_pam_unix_passwordauth_sha512:obj:1 of type textfilecontent54_object

Filepath	Pattern	Instance
/etc/pam.d/password-auth	^[\s]*password[\s]+(?:(?:required)|(?:sufficient))[\s]+pam_unix.so[\s]+.sha512.$

But during the installation, everything was fine:

set_password_hashing_algorithm_passwordauth - during remediaiton phase

check /etc/pam.d/password-auth for correct settings  oval:ssg-test_pam_unix_passwordauth_sha512:tst:1  true

Following items have been found on the system:

Path	Content
/etc/pam.d/password-auth	password sufficient pam_unix.so try_first_pass use_authtok nullok sha512 shadow

SCAP Security Guide Version:

11974e4

Operating System Version:

RHEL 9

Steps to Reproduce:

1. Install machine using profile kickstart (ANSSI, CIS Server L2, CIS Workstation L2, or PCI DSS profile)
2. After installation, scan the rules

Actual Results:

PAM rules fail

Expected Results:

PAM rules pass

Additional Information/Debugging Steps:

It might be related to how openscap remediates:

1. scanning all rules - enable_authselect fails and rules listed above pass
2. remediating failed rules - enable_authselect is remediated and thus overwrites all existing PAM configuration. The passed rules are not remediated even though their configuration might have been broken by the authselect select

[mildas]

@yuumasato @marcusburghardt Thoughts on the Additional Information/Debugging Steps?

[vojtapolasek]

So I did a test on fresh RHEL9 install. I installed without any hardening. First I did only oscap xccdf eval for some rules. Here are results: enable_authselect - FAIL set_password_hashing_algorithm_passwordauth - PASS set_password_hashing_algorithm_systemauth - PASS accounts_password_pam_retry - PASS Then I ran remediation for enable_authselect, which reported as FIXED. then I did eval for the same rules again with the following result: enable_authselect - PASS set_password_hashing_algorithm_passwordauth - PASS set_password_hashing_algorithm_systemauth - PASS accounts_password_pam_retry - FAIL Which supports @mildas assumption. Then I remediated the rule accounts_password_pam_retry and all 4 rules were passing.

[marcusburghardt]

Thanks for the analysis on this @mildas and @vojtapolasek. With the problem clear I could analyse possible solutions and found a possible easy fix here. Basically the remediation should not select a profile if one is already in use. I can send a fix for this tomorrow.

[mildas]

@marcusburghardt I don't think it will help. Not selecting a profile if one is already in use should be prevented via https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/system/accounts/enable_authselect/bash/shared.sh#L8

Those fails were caught on clean machine where no authselect profile has been selected.

[marcusburghardt]

Correct @mildas. This morning I reviewed the idea with a fresh head and a new testing VM. I saw it is not so easy as I thought. : (.

So, in a system without an active authselect profile, this is the state of /etc/pam.d directory:

ls -lah /etc/pam.d/
-rw-r--r--.  1 root root  272 Aug  9  2021 atd
-rw-r--r--.  1 root root  192 Feb 24 11:25 chfn
-rw-r--r--.  1 root root  192 Feb 24 11:25 chsh
-rw-r--r--.  1 root root  728 Mar  2 15:58 cockpit
-rw-r--r--.  1 root root  232 Dec  2  2021 config-util
-rw-r--r--.  1 root root  322 Feb 15  2019 crond
-rw-r--r--.  1 root root  701 Dec  2  2021 fingerprint-auth
-rw-r--r--.  1 root root  676 Feb 24 11:25 login
-rw-r--r--.  1 root root  154 Dec  2  2021 other
-rw-r--r--.  1 root root  168 Aug 10  2021 passwd
-rw-r--r--.  1 root root  760 Dec  2  2021 password-auth
-rw-r--r--.  1 root root  155 Mar 11 16:32 polkit-1
-rw-r--r--.  1 root root  398 Dec  2  2021 postlogin
-rw-r--r--.  1 root root  640 Feb 24 11:25 remote
-rw-r--r--.  1 root root  143 Feb 24 11:25 runuser
-rw-r--r--.  1 root root  138 Feb 24 11:25 runuser-l
-rw-r--r--.  1 root root  743 Dec  2  2021 smartcard-auth
-rw-r--r--.  1 root root  727 Feb 22 13:42 sshd
-rw-r--r--.  1 root root  214 Dec 23  2021 sssd-shadowutils
-rw-r--r--.  1 root root  566 Feb 24 11:25 su
-rw-r--r--.  1 root root  137 Feb 24 11:25 su-l
-rw-r--r--.  1 root root   97 Apr 13 17:00 subscription-manager
-rw-r--r--.  1 root root  154 Aug 26  2021 sudo
-rw-r--r--.  1 root root  178 Aug 26  2021 sudo-i
-rw-r--r--.  1 root root  760 Dec  2  2021 system-auth
-rw-r--r--.  1 root root  248 Apr  7 16:01 systemd-user
-rw-r--r--.  1 root root   84 Jan 18 10:31 vlock

When an authselect profile is selected, symlinks for some files are created, like this:

ls -lah /etc/pam.d/
drwxr-xr-x.  2 root root 4.0K Jun 30 15:17 .
drwxr-xr-x. 86 root root 8.0K Jul 14 07:53 ..
-rw-r--r--.  1 root root  232 Dec  2  2021 config-util
-rw-r--r--.  1 root root  322 Feb 15  2019 crond
lrwxrwxrwx.  1 root root   32 Jun 30 15:03 fingerprint-auth -> /etc/authselect/fingerprint-auth
-rw-r--r--.  1 root root  676 Feb 24 10:25 login
-rw-r--r--.  1 root root  154 Dec  2  2021 other
-rw-r--r--.  1 root root  168 Aug 10  2021 passwd
lrwxrwxrwx.  1 root root   29 Jun 30 15:03 password-auth -> /etc/authselect/password-auth
-rw-r--r--.  1 root root  155 Mar 11 15:32 polkit-1
lrwxrwxrwx.  1 root root   25 Jun 30 15:03 postlogin -> /etc/authselect/postlogin
-rw-r--r--.  1 root root  640 Feb 24 10:25 remote
-rw-r--r--.  1 root root  143 Feb 24 10:25 runuser
-rw-r--r--.  1 root root  138 Feb 24 10:25 runuser-l
lrwxrwxrwx.  1 root root   30 Jun 30 15:03 smartcard-auth -> /etc/authselect/smartcard-auth
-rw-r--r--.  1 root root  727 Feb 22 12:42 sshd
-rw-r--r--.  1 root root  214 Dec 23  2021 sssd-shadowutils
-rw-r--r--.  1 root root  566 Feb 24 10:25 su
-rw-r--r--.  1 root root   97 Apr 13 15:00 subscription-manager
-rw-r--r--.  1 root root  154 Aug 26  2021 sudo
-rw-r--r--.  1 root root  178 Aug 26  2021 sudo-i
-rw-r--r--.  1 root root  137 Feb 24 10:25 su-l
lrwxrwxrwx.  1 root root   27 Jun 30 15:03 system-auth -> /etc/authselect/system-auth
-rw-r--r--.  1 root root  248 Apr  7 14:01 systemd-user
-rw-r--r--.  1 root root   84 Jan 18 09:31 vlock

For this reason, the enable_authselect rule fails in a system without a selected authselect profile. This is expected.

So, the issue is related to the accounts_password_pam_retry rule. The system default PAM files have the retry option defined by default for pam_pwquality.so module:

grep -r pwquality /etc/pam.d/
/etc/pam.d/password-auth:password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
/etc/pam.d/system-auth:password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=

So, the accounts_password_pam_retry rule pass before applying the first remediation round. However, the PAM files included in authselect profiles are not defining the retry option for pam_pwquality.so module:

grep -r pwquality /usr/share/authselect/default/
/usr/share/authselect/default/minimal/password-auth:password    requisite                                    pam_pwquality.so try_first_pass
/usr/share/authselect/default/minimal/system-auth:password    requisite                                    pam_pwquality.so try_first_pass
/usr/share/authselect/default/sssd/password-auth:password    requisite                                    pam_pwquality.so try_first_pass local_users_only
/usr/share/authselect/default/sssd/system-auth:password    requisite                                    pam_pwquality.so try_first_pass local_users_only
/usr/share/authselect/default/winbind/password-auth:password    requisite                                    pam_pwquality.so try_first_pass local_users_only
/usr/share/authselect/default/winbind/system-auth:password    requisite                                    pam_pwquality.so try_first_pass local_users_only

Consequently, the accounts_password_pam_retry rule fails after applying the first remediation round.

This would be tricky to fix and sincerely, I don't think this is a real issue. In a compliant system where authselect tool is available, it is expected that authselect is used. If this is the case since the beginning, there is no problem. However, if a system is installed without selecting an authselect profile, this should be fixed as the enable_authselect rule does. This can naturally drive to other issues if the authselect profiles are not aligned to the default system files, like in this case of pam_pwquality.so.

So, one option would be to recommend the authselect maintainers to update the profiles. This can solve this specific problem now but it is not guaranteed that the files differentiate again at some point. Another much simpler option would be to execute the assessment and remediation again. I think this is expected in these situation and based on that I defend this is not a real issue or, at least, not a critical issue.

[mildas]

There is no easy fix - must be fixed on scanner side.

[marcusburghardt]

Should we close it here and open a new issue in OpenSCAP?

[matusmarhefka]

Closing, reported an issue in openscap - https://github.com/OpenSCAP/openscap/issues/1880