Bug 2106857
| Summary: | grub2_disable_interactive_boot is not UEFI aware | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Jiri Jaburek <jjaburek> |
| Component: | scap-security-guide | Assignee: | Matěj Týč <matyc> |
| Status: | CLOSED DUPLICATE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 9.1 | CC: | ggasparb, jpazdziora, maburgha, matyc, mhaicman, mlysonek, openscap-maint, vpolasek |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-08-10 09:48:33 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: | |||
Hello Jiri, would it be acceptable to split this into two rules? One would take care about removing any instance of argument systemd.confirm_spawn from Grub2 boot line and the rest would be handled by already existing rule grub2_disable_recovery. (In reply to Vojtech Polasek from comment #2) > Hello Jiri, > would it be acceptable to split this into two rules? One would take care > about removing any instance of argument systemd.confirm_spawn from Grub2 > boot line and the rest would be handled by already existing rule > grub2_disable_recovery. I mean - sure, I don't really know what systemd.confirm_spawn has to do with this BZ, but as long as the functionality covered by grub2_disable_interactive_boot works on UEFI too, feel free to split/merge rules how you see fit. Hello, I believe this is fixed in scap-security-guide-0.1.63-1.el9. It was actually fixed as part of this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2092809 Can you confirm? I can still see the issue with scap-security-guide-0.1.63-1.el8.noarch (for RHEL-8.7) from Brew. # oscap xccdf generate --profile ospp fix --output out.sh --fix-type bash /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml # grep 'grub2-mkconfig -o /boot/grub2/grub.cfg' out.sh grub2-mkconfig -o /boot/grub2/grub.cfg # rpm -q scap-security-guide scap-security-guide-0.1.63-1.el8.noarch I can however confirm the problem is gone on RHEL-9, # oscap xccdf generate --profile ospp fix --output out.sh --fix-type bash /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml # grep 'grub2-mkconfig -o /boot/grub2/grub.cfg' out.sh # rpm -q scap-security-guide scap-security-guide-0.1.63-1.el9.noarch I am closing the BZ as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2092809. It is not a duplicate per se, but that BZ fixes the issue, as it has been confirmed also by the reporter. Regarding RHEL8, an analogous BZ exists there as well: https://bugzilla.redhat.com/show_bug.cgi?id=2116440 *** This bug has been marked as a duplicate of bug 2092809 *** Hello, I'd like to point out that on RHEL 9, it is actually correct that any changes end up in /boot/grub2/grub.cfg and not in /boot/efi/EFI/redhat/grub.cfg. Per https://fedoraproject.org/wiki/Changes/UnifyGrubConfig and https://docs.fedoraproject.org/en-US/quick-docs/bootloading-with-grub2/ the /boot/efi/EFI/redhat/grub.cfg is now just a small wrapper which contains only # cat /boot/efi/EFI/redhat/grub.cfg search --no-floppy --fs-uuid --set=dev 47c6c78f-f715-4c2e-996b-3f4d6eb9ffe1 set prefix=($dev)/grub2 export $prefix configfile $prefix/grub.cfg to load /boot/grub2/grub.cfg. So should any rule need / want to regenerate the GRUB config file directly for example when the grubby mechanism cannot be used, on RHEL 9 it really should use grub2-mkconfig -o /boot/grub2/grub.cfg and not grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg. I understand that the specific issue of grub2_disable_interactive_boot was addressed in 2092809 by new rule grub2_disable_recovery which in scap-security-guide-0.1.63-1.el9 uses grubby but it might be useful to cross-check the use of grub2-mkconfig in the datastream in general. |
Description of problem: The current RHEL-9.1 content remediates this when using a RHEL-9 ospp profile: ... #Regen grub.cfg handle updated GRUB_DISABLE_RECOVERY and confirm_spawn grub2-mkconfig -o /boot/grub2/grub.cfg (this can be seen in a oscap xccdf generate --profile ospp fix). The problem is that the ospp profile is generally used on UEFI systems (due to Secure Boot) and /boot/efi/EFI/*/grub.cfg is used instead of /boot/grub2/grub.cfg, which is ignored. There seem to be other grub2 rules that seem to be uefi aware (versus others that are not), https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/system/bootloader-grub2/uefi https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/system/bootloader-grub2/non-uefi so maybe two versions of the grub2_disable_interactive_boot rule would make sense, for both {{{ grub2_uefi_boot_path }}} and {{{ grub2_boot_path }}}. (Or another solution that would ensure an UEFI remediation script for the ospp profile.) Note that this remediation script is not present in the RHEL-9.0 GA release version of scap-security-guide, it was added later during RHEL-9 lifecycle. Version-Release number of selected component (if applicable): scap-security-guide-0.1.62-1.el9 Additional info: This is a downstream version of https://github.com/ComplianceAsCode/content/issues/9044 .