Crypto-policy-related rules fail on RHEL-8 when installed with fips=1

[comps]

Description of problem:

harden_sshd_ciphers_openssh_conf_crypto_policy
harden_sshd_ciphers_opensshserver_conf_crypto_policy
harden_sshd_macs_openssh_conf_crypto_policy
harden_sshd_macs_opensshserver_conf_crypto_policy

fail on RHEL-8 (stig and stig_gui) when using the content-provided Anaconda kickstarts, when the installer is booted with fips=1, as opposed to RHEL-9 where these also fail, but don't have any remediation, so a potential failure is presumably expected.

In addition,

configure_gnutls_tls_crypto_policy

also fails on RHEL-8, and that rule doesn't seem to be part of any relevant RHEL-9 profile.

And

configure_crypto_policy

fails with the ospp profile, also only seems to be on RHEL-8.

SCAP Security Guide Version:

master @ cfed082

Operating System Version:

RHEL-8

Steps to Reproduce:

1. Run Contest as --rhel 8 --arch x86_64 --test "/hardening/anaconda/(stig|ospp)", possibly with CONTENT_PR=12916 (Update rule enable_fips_mode for RHEL 10 #12916) if it is not merged in the meantime.

Additional Information/Debugging Steps:

• stig-arf.xml.gz
• ospp-arf.xml.gz

[comps]

The configure_crypto_policy rule seems to pass for non-ospp profiles, so it might be related to FIPS versus FIPS:OSPP crypto policy.

[jan-cerny]

The rule configure_crypto_policy fails in test /hardening/anaconda/ospp on RHEL 8 because the OSPP profile requires the policy to be set to FIPS:OSPP, but the actual state of the policy is FIPS. This is a known bug in Anaconda: https://issues.redhat.com/browse/RHEL-4722.

For the same reason the rule enable_fips_mode fails the same test as well.

We will add enable_fips_mode to contest waivers in RHSecurityCompliance/contest#326

[jan-cerny]

I have investigated the RHEL 8 STIG profile. I have used current upstream master as of 2025-02-06 as of HEAD 47fd3bc. I have run the test /hardening/anaconda/stig on a remote VM running RHEL 8.10. I have run the following command:

./autocontest.sh test -t '/hardening/anaconda/stig' -h <HOSTNAME>   --content-path /home/jcerny/work/git/scap-security-guide/  

First, I have focused on rule configure_gnutls_tls_crypto_policy. This rule requires that the file /etc/crypto-policies/back-ends/gnutls.config content equals to +VERS-ALL:-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0.

The rule has been evaluated as false in the after reboot scan. However, the rule has been evaluated as fixed during OSCAP Anaconda Addon run of oscap during the system installation. That means that something changed between the remediation execution and after reboot scan.

The file /etc/crypto-policies/back-ends/gnutls.config is owned by the crypto-policies RPM package. Our remedation owerwrites the contents of the file. However, the modification time of the file is about 2 minutes later than the time in the OSCAP Anaconda Addon HTML report.

[root@localhost ~]# stat -c %y /etc/crypto-policies/back-ends/gnutls.config
2025-02-07 04:02:58.045061372 -0500

This corresponds with what I found in the log /var/log/anaconda/journal.log, I think this is only using a different time zone:

Feb 07 09:00:08 localhost.localdomain anaconda[2178]: anaconda: misc: OSCAP addon: Executing subprocess: 'oscap xccdf eval --remediate --results=/root/openscap_data/eval_remediate_results.xml --report=/root/openscap_data/eval_remediate_report.html --profile=stig /root/openscap_data/remediation-ds.xml'

....


Feb 07 09:01:38 localhost.localdomain oscap[40497]: Evaluation finished. Return code: 2, Base score 61.348789.

At the second of the last modification of the /etc/crypto-policies/back-ends/gnutls.config file, we can see in /var/log/anaconda/journal.log, that the crypto policies have been set:

Feb 07 09:02:58 localhost.localdomain anaconda[2178]: program: Kernel initramdisks are being regenerated. This might take some time.
Feb 07 09:02:58 localhost.localdomain anaconda[2178]: program: Setting system policy to FIPS
Feb 07 09:02:58 localhost.localdomain anaconda[2178]: program: Note: System-wide crypto policies are applied on application start-up.
Feb 07 09:02:58 localhost.localdomain anaconda[2178]: program: It is recommended to restart the system for the change of policies
Feb 07 09:02:58 localhost.localdomain anaconda[2178]: program: to fully take place.
Feb 07 09:02:58 localhost.localdomain anaconda[2178]: program: FIPS mode will be enabled.
Feb 07 09:02:58 localhost.localdomain anaconda[2178]: program: Now you need to configure the bootloader to add kernel options "fips=1 boot=UUID=937a8aa7-311d-4a25-afac-4c652195d23d"
Feb 07 09:02:58 localhost.localdomain anaconda[2178]: program: and reboot the system for the setting to take effect.
Feb 07 09:02:58 localhost.localdomain anaconda[2178]: program: Return code: 0
Feb 07 09:02:58 localhost.localdomain anaconda[2178]: anaconda: progress: Generate initramfs

I think that this action could overwrite our modification of file /etc/crypto-policies/back-ends/gnutls.config and revert it to be symlink provided by crypto-policies RPM package.

The same problem situation happens also with rules sshd_ciphers_opensshserver_conf_crypto_policy and sshd_macs_opensshserver_conf_crypto_policy.

[jan-cerny]

The same problem situation happens also with rules sshd_ciphers_opensshserver_conf_crypto_policy and sshd_macs_opensshserver_conf_crypto_policy. But in these 2 rules there are addintionally 2 suspicious messages produced by remeditaion:

harden_sshd_ciphers_opensshserver_conf_crypto_policy:

grep: [email protected],[email protected],aes256-ctr,aes128-ctr: invalid context length argument

harden_sshd_macs_opensshserver_conf_crypto_policy:

grep: invalid option -- 'M'
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.

[jan-cerny]

I think it can be related to https://issues.redhat.com/browse/RHEL-4722.

[jan-cerny]

The other 2 rules (harden_sshd_macs_openssh_conf_crypto_policy and harden_sshd_ciphers_openssh_conf_crypto_policy) were removed this week from the RHEL 8 STIG profile. #12949