ComplianceAsCode
Crypto-policy-related rules fail on RHEL-8 when installed with `fips=1`
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 @ cfed0829f21b8baca8e702c37474fd04f500e651
Operating System Version:
RHEL-8
Steps to Reproduce:
- Run Contest as
--rhel 8 --arch x86_64 --test "/hardening/anaconda/(stig|ospp)", possibly withCONTENT_PR=12916(#12916) if it is not merged in the meantime.
Additional Information/Debugging Steps:
The configure_crypto_policy rule seems to pass for non-ospp profiles, so it might be related to FIPS versus FIPS:OSPP crypto policy.
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 https://github.com/RHSecurityCompliance/contest/pull/326
I have investigated the RHEL 8 STIG profile. I have used current upstream master as of 2025-02-06 as of HEAD 47fd3bcded59116ade8ea09eb396f363e37813d4. 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.
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.
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. https://github.com/ComplianceAsCode/content/pull/12949
I confirm that with the current upstream master as of 2024-02-28 as of HEAD 5a8c0c92708125d4e2f9a091923937fffded0b68 the following rules fail the /hardening/anaconda/stig contest test on RHEL 8.10:
- configure_gnutls_tls_crypto_policy
- harden_sshd_ciphers_opensshserver_conf_crypto_policy
- harden_sshd_macs_opensshserver_conf_crypto_policy
As outlined in previous comments, the reason is that when the system installation is started in FIPS mode, Anaconda overwrites custom changes of respective configuration files that have been done by our remediations run by OSCAP Anaconda Addon. (this is tracked in https://issues.redhat.com/browse/RHEL-4722)
Therefore this ticket is still not fixed.