Ansible STIG on Centos Stream 8 fails on crypto policies related rules (testing-farm:centos-stream-8-x86_64)

[ggbecker]

Description of problem:

https://github.com/ComplianceAsCode/content/runs/15884049912

:: [ 17:19:52 ] :: [   FAIL   ] :: Rules not passing after remediation:

xccdf_org.ssgproject.content_rule_configure_gnutls_tls_crypto_policy - fail

xccdf_org.ssgproject.content_rule_harden_sshd_ciphers_openssh_conf_crypto_policy - fail

xccdf_org.ssgproject.content_rule_harden_sshd_ciphers_opensshserver_conf_crypto_policy - fail

xccdf_org.ssgproject.content_rule_harden_sshd_macs_openssh_conf_crypto_policy - fail

xccdf_org.ssgproject.content_rule_harden_sshd_macs_opensshserver_conf_crypto_policy - fail

Additional Information/Debugging Steps:

The requirement for the test testing-farm:centos-stream-8-x86_64 has been disabled temporarily until this problem is solved.

[ggbecker]

Here is the HTML report: https://artifacts.dev.testing-farm.io/0c32a048-e3e9-4e62-9187-2ebd48c8ab79/work-ansible-stig7hwfuudf/tests/fmf-plans/ansible-stig/execute/data/guest/default-0/Sanity/ansible-machine-hardening/stig-1/data/stig.html

there is also the sos-report in this folder if one needs to look into configuration files: https://artifacts.dev.testing-farm.io/0c32a048-e3e9-4e62-9187-2ebd48c8ab79/work-ansible-stig7hwfuudf/tests/fmf-plans/ansible-stig/execute/data/guest/default-0/Sanity/ansible-machine-hardening/stig-1/data/

[ggbecker]

The ansible output shows that tasks changed the system, so one would expect that the files would contain the expected configuration lines, but they are not there. It's still unclear if the change happens but gets reverted after the machine is rebooted.

[matejak]

This looks pretty much like #10664, and although the issue has been solved for RHEL9 by removing the rules, the same solution can't be applied to RHEL8, as unlike with RHEL9, those rules are to basically correct.

However, with RHEL9, the same behavior was observed - rules haven't survived the reboot, and I haven't been able to reproduce it at that time, and finding a reproducer also turned out as not necessary. It may be that the Crypto Policy is somehow reset between the remediation and the subsequent scan. A reboot alone is not enough for the reset, there have to be some unknown additional conditions.

From what I remember:

• It is not a conflict between filesystem and RPM integrity, modified files are probably considered to be configurations.
• Rules modify paths that are, in fact, symlinks. Once a reproducer is found, it could make sense to remove symlinks and put actual files in their places instead.
• Ideally, we should not edit those files, but we should be using a Crypto Policy module s.a. FIPS:OSPP or something else.

[ggbecker]

The test started passing without any intervention. It was a problem with the Centos Stream compose and we were not able to identify what exactly was. This can be closed and the required test testing-farm:centos-stream-8-x86_64 will be re-enabled soon.

[ggbecker]

The test is re-enabled as required again.