PAM rule false positive

[rwmanos]

Description of problem:

The 'Ensure PAM Enforces Password Requirements - Prevent the Use of Dictionary Words' rule fails, for example on a RHEL9 node, when the dictcheck option is commented out.

Details:

Reproduce:

$ grep dictcheck /etc/security/pwquality.conf
# dictcheck = 1
$ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis --report report.html --rule xccdf_org.ssgproject.content_rule_accounts_password_pam_dictcheck /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
--- Starting Evaluation ---

Title   Ensure PAM Enforces Password Requirements - Prevent the Use of Dictionary Words
Rule    xccdf_org.ssgproject.content_rule_accounts_password_pam_dictcheck
Ident   CCE-88413-0
Result  fail

In the OVAL test results details, the first test is true but the second is false
check the configuration of /etc/pam.d/system-auth -> true
check the configuration of /etc/security/pwquality.conf -> false

oval:ssg-test_password_pam_pwquality_dictcheck:tst:1  false
No items have been found conforming to the following objects:
Object oval:ssg-obj_password_pam_pwquality_dictcheck:obj:1 of type textfilecontent54_object
Filepath	Pattern	Instance
^/etc/security/pwquality\.conf(\.d/[^/]+\.conf)?$	^\s*dictcheck[\s]*=[\s]*(-?\d+)(?:[\s]|$)	1

From what I understand, it fails because the 'dictcheck' line is commented out and it only passes when it is set AND it is set to 1.

However, this seems too strict. For example, CIS_Red_Hat_Enterprise_Linux_9_Benchmark_v2.0.0 defines that you need to verify that the dictcheck option is not set to 0 (disabled). And commenting it out is a valid remediation. This is also supported by the man page since the default value of dictcheck is 1 in pwquality.conf.

Could you adjust this rule to fail if and only if the option is set to 0?

Outcome:

• This project's content can be improved:
  • Check needs to be improved.
  • Remediation needs to be improved.
• The external content's check is faulty - the other party needs to be notified, they have work to do.

SCAP Security Guide Version:

$ cat /etc/redhat-release
Red Hat Enterprise Linux release 9.7 (Plow)
$ rpm -q openscap scap-security-guide
openscap-1.3.12-1.el9_6.x86_64
scap-security-guide-0.1.79-1.el9.noarch

[Mab879]

Thanks for opening this issue.

We reuse this rule for the RHEL STIG and it requires that dcredit is not commented out. In order to accommodate this we would have to create a bunch of duplicate rules (for the other credits) that duplicates that accept the default value. I'm afraid the maintenance overhead might not be worth it.

I will also note that this project generally prefers to be explicit, over default behavior (which may change).

@vojtapolasek thoughts?

[rwmanos]

Thank you for checking it. It's actually about dictcheck but the behavior is the same as for dcredit indeed.

Please note that I have identified more inconsistencies which I still needed to verify and I wanted to see how this first issue goes :-) However, I see this is becoming a more generic topic.

All the "RHEL 9 must disable the XXXX kernel module" are also more strict. CIS is satisfied if the kernel module is not available on the system, or pre-compiled into the kernel. While RHEL STIG requires it blacklisted nevertheless.

In conclusion, the RHEL STIG rules are more aggressive. And if you want to comply, for example, with CIS, there are some false positives. My recommendation would be:

• Influence the RHEL STIG to not be so unnecessarily strict. Explicitly declaring a default value brings no security benefit and it requires unnecessary changes that people might distrust.
• Create custom CIS modifications so that the tool has better coverage. If not possible, write a disclaimer about CIS coverage on the main page/script output.