Many rules in RHEL 9 STIG profile fail after remediation and reboot

jan-cerny commented 2 years ago

Description of problem:

In the machine-hardening STIG test a lot of rules fail after remediation and reboot.

SCAP Security Guide Version:

current upstream as of 2022-08-29 as of HEAD dcbae8cca1276ec8046f7c682bdafcf86b239e19

Operating System Version:

RHEL 9.1

Steps to Reproduce:

oscap xccdf eval --progress --remediate --profile xccdf_org.ssgproject.content_profile_stig --report /stig_remediate_report.html ssg-rhel9-ds.xml
reboot
oscap xccdf eval --progress --profile xccdf_org.ssgproject.content_profile_stig --results stig-xccdf-results.xml --report stig.html ssg-rhel9-ds.xml

Actual Results:

xccdf_org.ssgproject.content_rule_rpm_verify_hashes - fail xccdf_org.ssgproject.content_rule_rpm_verify_permissions - fail xccdf_org.ssgproject.content_rule_display_login_attempts - fail xccdf_org.ssgproject.content_rule_account_password_selinux_faillock_dir - fail xccdf_org.ssgproject.content_rule_account_passwords_pam_faillock_audit - fail xccdf_org.ssgproject.content_rule_accounts_password_pam_pwhistory_remember_password_auth - fail xccdf_org.ssgproject.content_rule_accounts_password_pam_pwhistory_remember_system_auth - fail xccdf_org.ssgproject.content_rule_accounts_password_pam_unix_remember - fail xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny - fail xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny_root - fail xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_interval - fail xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time - fail xccdf_org.ssgproject.content_rule_no_empty_passwords - fail xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_shadow - fail xccdf_org.ssgproject.content_rule_sssd_enable_smartcards - fail

Expected Results:

All the aforementioned rules pass or waivers are set up.

Additional Information/Debugging Steps:

marcusburghardt commented 2 years ago

The PAM related rules are failing because the enable_authselect rule is not selected in RHEL9 STIG profile. Regarding the rpm_verify, I didn't check.

jan-cerny commented 2 years ago

@marcusburghardt the rpm_verify_permissions might be related to crypto policy problem: https://github.com/ComplianceAsCode/content/issues/9385

jan-cerny commented 2 years ago

This issue also happens in the "test-profiles-remediation PCI-DSS, OSPP, STIG" test on RHEL 9.1 where we run profile mode and we executed this Automatus command:

python3 /tmp/tmp.iFaAKKETOR/rpmbuild/BUILD/scap-security-guide-0.1.64/tests/test_suite.py profile --libvirt qemu:///system test_suite_vm --datastream /tmp/ssg-rhel9-ds.xml --xccdf-id scap_org.open-scap_cref_ssg-rhel9-xccdf-1.2.xml --mode online --remediate-using oscap xccdf_org.ssgproject.content_profile_stig

jan-cerny commented 2 years ago

This issue also happens in "test-profiles-remediation PCI-DSS, OSPP, STIG_GUI (GUI)" test on RHEL 9.1 where we run profile mode and we executed this Automatus command: python3 /tmp/tmp.Lu9mAT32mi/rpmbuild/BUILD/scap-security-guide-0.1.64/tests/test_suite.py profile --libvirt qemu:///system test_suite_vm --datastream /tmp/ssg-rhel9-ds.xml --xccdf-id scap_org.open-scap_cref_ssg-rhel9-xccdf-1.2.xml --mode online --remediate-using oscap xccdf_org.ssgproject.content_profile_stig_gui

marcusburghardt commented 2 years ago

The #9439 is merged and the PAM related rules should no longer fail in RHEL9 STIG.

marcusburghardt commented 2 years ago

The account_password_selinux_faillock_dir was fixed by #9381 and #9421

marcusburghardt commented 2 years ago

The following rules are pending investigation:

xccdf_org.ssgproject.content_rule_rpm_verify_hashes - fail
xccdf_org.ssgproject.content_rule_rpm_verify_permissions - fail
xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_shadow - fail

ggbecker commented 2 years ago

The following rules are pending investigation:

* xccdf_org.ssgproject.content_rule_rpm_verify_hashes - fail

* xccdf_org.ssgproject.content_rule_rpm_verify_permissions - fail

* xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_shadow - fail

and this: xccdf_org.ssgproject.content_rule_sssd_enable_smartcards - fail

are still failing on latest master

mildas commented 2 years ago

audit_rules_usergroup_modification_shadow - check https://bugzilla.redhat.com/show_bug.cgi?id=2119356 It might not be reproducible on clean machine, you need specific file to exist, see the BZ.

ggbecker commented 2 years ago

The rule following rule

xccdf_org.ssgproject.content_rule_rpm_verify_permissions - fail

Fails because the RHEL9 STIG profile selects rules like:

https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/services/cron_and_at/file_permissions_cron_hourly/rule.yml#L53

and these rules change the file permissions of /etc/cron* folders and those are regulated by the rpm database, deviating from its original state. The viability of those changes in the cron package itself is something to be discussed because the permissions are quite strict and and maybe is not a good idea to generalize that. For now the rule will be waived in our upstream testing farm tests and further actions need to be taken, whether allowing less stricter permissions on our rules or influencing the cron packaging developers to change the default permissions of that folders.

Waiver for rule in the STIG harderning test: https://src.fedoraproject.org/tests/scap-security-guide/pull-request/12

ggbecker commented 2 years ago

Let's close this one and create focused issues depending on items left with unexpected failures.

marcusburghardt commented 2 years ago

audit_rules_usergroup_modification_shadow - check https://bugzilla.redhat.com/show_bug.cgi?id=2119356 It might not be reproducible on clean machine, you need specific file to exist, see the BZ.

There is a merged PR (#9463) mentioned in this BZ. I checked the BZ, the PR and the issue seems to be fixed.

marcusburghardt commented 2 years ago

Let's close this one and create focused issues depending on items left with unexpected failures.

I quickly reviewed and it seems that all the mentioned rules were already tackled recently and are no longer failing. I couldn't confirm in details that all issues were solved. However, it is difficult to track this issue at this point since many different rules were mentioned. So, I totally support to close this issue and, if any of the mentioned rules fails, we open a separate issue for each individual rule.

ComplianceAsCode / content