RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1754532 - Rule grub2_enable_fips_mode fails after kickstart installation
Summary: Rule grub2_enable_fips_mode fails after kickstart installation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: scap-security-guide
Version: 7.8
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: 7.8
Assignee: Gabriel Gaspar Becker
QA Contact: Vojtech Polasek
Eric Christensen
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-23 13:44 UTC by Milan Lysonek
Modified: 2020-11-14 05:04 UTC (History)
7 users (show)

Fixed In Version: scap-security-guide-0.1.46-5.el7
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-31 19:38:15 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
oscap scan results for ospp profile (9.48 MB, application/xml)
2019-09-23 13:44 UTC, Milan Lysonek 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:1019 0 None None None 2020-03-31 19:38:35 UTC

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 6 Matěj Týč 2019-11-11 14:24:42 UTC 
https://github.com/ComplianceAsCode/content/pull/4986
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
Note You need to log in before you can comment on or make changes to this bug.