-
Bug
-
Resolution: Won't Do
-
Undefined
-
None
-
rhel-9.4
-
None
-
None
-
None
-
sst_security_compliance
-
ssg_security
-
None
-
False
-
-
None
-
None
-
None
-
None
-
None
What were you trying to do that didn't work?
When OAA performs a SCAP profile remediation, OpenSCAP reads data about systemd units from the installer environment instead of the installed system.
This leads to problems when some systemd units that exist in the installed system don't exist in the installer system or are different. A rule can pass and then a remediation isn't executed even if it should.
In past, this bug was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1999587, we attempted to fix it by first-boot remediation but we didn't introduce that feature to RHEL and the bug was closed automatically.
Recently, this has been discovered during an investigation of upstream productization issue
https://github.com/ComplianceAsCode/content/issues/12097. Therefore, we are reporting the bug again.
Please provide the package NVR for which bug is seen:
- oscap-anaconda-addon-2.0.0-17.el9.noarch.rpm
- openscap-1.3.8-1.el9
- scap-security-guide built from current upstream master as of 2024-06-08 as of HEAD 7cde9d1
How reproducible:
deterministic
Steps to reproduce
- perform a installation of a RHEL 9.4 VM with CIS L2 profile using custom content from the version above
- run a scan against CIS L2 profile after first boot of the installed VM
Expected results
systemd-journal-remote_disabled passes
Actual results
systemd-journal-remote_disabled fails
