`anssi_bp28_enhanced` and `high` fails to boot on UEFI after Ansible remediation

Description of problem:

When remediating either of $subj profiles on a Secure Boot enabled system, the OS fails to reboot with:

[FAILED] Failed to mount /boot/efi.
See 'systemctl status boot-efi.mount' for details.
...
Starting default.target
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

and the systemctl status says

mount: /boot/efi: unknown filesystem type 'vfat'.

This can also be reproduced manually:

[root@localhost ~]# mount /boot/efi
mount: /boot/efi: unknown filesystem type 'vfat'.
[root@localhost ~]# modprobe vfat
modprobe: ERROR: could not insert 'vfat': Operation not permitted

It seems that the vfat.ko module cannot be loaded at this stage because the kernel is in a Secure Boot Lockdown mode,

[root@localhost ~]# dmesg | grep -i secure
[    0.000000] secureboot: Secure boot enabled
[    0.000000] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
[    0.002870] secureboot: Secure boot enabled

Which was remediated / enabled by sysctl_kernel_modules_disabled (or something similar).

Turns out there is active Ansible remediation for the rule, but Bash remediation has been disabled by https://github.com/ComplianceAsCode/content/pull/6586. Well, this issue is probably the real cause why.

This particular problem can be fixed by the equivalent of

cat > /etc/dracut.conf.d/load_vfat.conf <<EOF
force_drivers+=" vfat "
EOF

dracut -f

but there are more problems caused by the lockdown mode - ie. the boot continues and locks up on /run/systemd/generator/systemd-cryptsetup@*.service.

So we probably should not be automatically remediating something as dangerous, so please disable Ansible remediation for sysctl_kernel_modules_disabled (and we can test if that helped).

SCAP Security Guide Version:

master @ b79ef8779969e528749c653deb4d50ec5162fdb7

Operating System Version:

RHEL-9, probably RHEL-8, definitely RHEL-10

ComplianceAsCode / content