Bug 1754532

Summary: Rule grub2_enable_fips_mode fails after kickstart installation
Product: Red Hat Enterprise Linux 7 Reporter: Milan Lysonek <mlysonek>
Component: scap-security-guideAssignee: Gabriel Gaspar Becker <ggasparb>
Status: CLOSED ERRATA QA Contact: Vojtech Polasek <vpolasek>
Severity: medium Docs Contact: Eric Christensen <sparks>
Priority: high    
Version: 7.8CC: ggasparb, matyc, mhaicman, openscap-maint, sparks, tborcin, vpolasek
Target Milestone: rcKeywords: Bugfix
Target Release: 7.8   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: scap-security-guide-0.1.46-5.el7 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-31 19:38:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
oscap scan results for ospp profile none

Description Milan Lysonek 2019-09-23 13:44:01 UTC
Created attachment 1618199 [details]
oscap scan results for ospp profile

Description of problem:
After installing RHEL 7.8 with kickstart using either OSPP or STIG profile and then performing oscap xccdf eval, rule xccdf_org.ssgproject.content_rule_grub2_enable_fips_mode (Enable FIPS Mode in GRUB2) fails.


Version-Release number of selected component (if applicable):
scap-security-guide-0.1.46-1.el7.noarch.rpm 

How reproducible:
100%


Steps to Reproduce:
1. Install RHEL 7.8 with OSPP or STIG kickstart
2. Scan machine with "oscap xccdf eval --rule xccdf_org.ssgproject.content_rule_grub2_enable_fips_mode --profile xccdf_org.ssgproject.content_profile_ospp" (or "oscap xccdf eval --rule xccdf_org.ssgproject.content_rule_grub2_enable_fips_mode --profile xccdf_org.ssgproject.content_profile_stig")


Actual results:
xccdf_org.ssgproject.content_rule_grub2_enable_fips_mode is failing after kickstart installation.


Expected results:
xccdf_org.ssgproject.content_rule_grub2_enable_fips_mode passes after kickstart installation.


Additional info:
Oscap scan result for OSPP profile after OSPP kickstart installation is attached.

Comment 2 Gabriel Gaspar Becker 2019-11-06 10:37:46 UTC
Package dracut-fips-aesni is available only on x86_64 architecture. The OVAL checks for presence of this package so archs which doesn't have it available will fail.

Comment 3 Gabriel Gaspar Becker 2019-11-08 14:41:41 UTC
After some investigation, what is described in Comment 2 is not true. The package is available on other architectures the failure of this rule is being caused missing dracut-fips-aesni on processors which support AES hardware acceleration which can be verified by running:

$grep -m1 -o aes /proc/cpuinfo

If the processor has this capability then the OVAl check will test for presence of dracut-fips-aesni package. The anaconda remediation does not include this package as a requirement, so during installation phase this rule will always fail. Notice that if the machine is subscribed during installation phase, then the bash remediation will install correctly the package and the rule will pass, otherwise it won't.

Changing the Anaconda remediation for this rule seems to solve the issue, but OSCAP-Anaconda-Addon does not check for processor's capabilities thus it may end installing dracut-fips-aesni even if the processor doesn't support AES hardware acceleration.

Comment 7 Gabriel Gaspar Becker 2019-11-11 14:47:31 UTC
This patch https://github.com/ComplianceAsCode/content/pull/4805 also needs to be backported so the PR mentioned by Comment 6 can be applied as well.

Comment 13 errata-xmlrpc 2020-03-31 19:38:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1019