on a Secure Boot (UEFI) virtual machine results in
Remediating rule 255/491: 'xccdf_org.ssgproject.content_rule_mount_option_boot_efi_nosuid'
Remediation is not applicable, nothing was done
however a subsequent scan on a booted system fails, so it clearly is applicable there.
Is it possible that the efi partition is being added late in the process, so oscap remediation doesn't see it?
Maybe some other reason?
AFAICT - OSBuild does build an UEFI-capable qcow2 image, so it does work in both legacy BIOS and UEFI modes, but maybe oscap remediation doesn't try to remediate both ... ?
mount_option_boot_efi_nosuid seems to be using the standard mount_option template, nothing super custom.
Description of problem:
Remediating ie.
stig
using OSBuild (Image Builder) via an oscap-generated Blueprint, which containson a Secure Boot (UEFI) virtual machine results in
however a subsequent scan on a booted system fails, so it clearly is applicable there.
Is it possible that the efi partition is being added late in the process, so oscap remediation doesn't see it?
Maybe some other reason?
AFAICT - OSBuild does build an UEFI-capable qcow2 image, so it does work in both legacy BIOS and UEFI modes, but maybe
oscap
remediation doesn't try to remediate both ... ?mount_option_boot_efi_nosuid
seems to be using the standardmount_option
template, nothing super custom.SCAP Security Guide Version:
master @ b79ef8779969e528749c653deb4d50ec5162fdb7
Operating System Version:
RHEL-8, RHEL-9, probably RHEL-10 too
Steps to Reproduce:
oscap xccdf generate --profile stig fix --fix-type blueprint datastream.xml
virt-install
, but add--boot firmware=efi,loader_secure=yes
to thevirt-install
CLI to make it create an UEFI / Secure Boot VMoscap xccdf eval
, the fail should be there