[8.6] OpenSCAP anssi bp28 high broken -> No boot


I am testing openscap profiles for almalinux and I found that if you directly remediate with anssi bp28 high profile, system does not boot. That happens both if you install with that profile selected or if you manually apply profile latter wish oscap xccdf eval --remediate

After reboot emergency console shows and there you can find that the problem is that /boot/efi could not be mounted.

#journalctl -xb 
systemd[1]: Failed to mount /boot/efi.

I do not have found were in the profile remediation vfat filesystem is forbbiden.

# modprobe -v vfat
insmod /lib/modules/4.18.0-372.19.1.el8_6.x86_64/kernel/fs/fat/fat.ko.xz
modprobe: ERROR: could not insert 'vfat': Operation not permitted

It is not blacklisted on modprobe.d files, checked /etc/modprobe.d [/usr]/lib/modprobe.d/
Secure boot is enabled. But I saw no difference disabling it.

Workarround could be to comment /boot/efi entry in /etc/fstab, but that only allows you to start, if grub/kernel packages needed to be upgraded there will not upgrade content of real /boot/efi (you could manually select new kernel on boot menu to start), so no long term solution.

Any thought will be welcomed.

Best Regards,


1 Like


Seems that is a selinux related configuration.
With SELINUX=permissive in /etc/selinux/config is it possible again to mount /boot/efi

Now I will look for the selinux rule that affects it.

Best Regards,



any luck finding the vfat blocking SELINUX configuration ? Could you please share ?


Sorry, unfortunatelly I could not dedicate the time needed to continue with it yet



so I checked what can be the issue with SELINUX and with the security hardening comes a SELINUX boolean into play called secure_mode_insmod. This is very ‘generic’ one, based on documentation, which should not allow any processes to load kernel modules.
I think, the boolean(whole policy) it is loaded too early in boot process and creates obstruction to load vfat (probably if you have some other software in boot process, like proprietary antivirus, which like to load module, it could obstruct also those…).

After disabling it, I was able to load and unload (also blocks unloading) vfat kernel module.

Funny stuff is, none of the blocking (during load and unload) was logged in audit.log…so the usual tools to find and process DENIED AVCs were not useful at all.

[root@template ~]# setsebool secure_mode_insmod 1
[root@template ~]# modprobe -v vfat
insmod /lib/modules/5.14.0-162.6.1.el9_1.x86_64/kernel/fs/fat/fat.ko.xz
modprobe: ERROR: could not insert ‘vfat’: Operation not permitted

[root@template ~]# setsebool secure_mode_insmod 0
[root@template ~]# modprobe -v vfat
insmod /lib/modules/5.14.0-162.6.1.el9_1.x86_64/kernel/fs/fat/fat.ko.xz
insmod /lib/modules/5.14.0-162.6.1.el9_1.x86_64/kernel/fs/fat/vfat.ko.xz


yes i found that insmod restriction a bit OTT, think i got bitten when trying to load an iptables module or something. it seems like it should be set right at the end of the boot process.

There is a fstype for efi. Try this in kickstart;

part /boot/efi --fstype=efi --label EFI --size=600


  1. Permanently set the “secure_mode_insmod” boolean to “false”:

[root@localhost ~]# setsebool -P secure_mode_insmod false

  1. Create a script that enables the boolean, /usr/local/sbin/setsebool_insmod.sh :

setsebool secure_mode_insmod true

  1. Set permissions on the script:

[root@localhost ~]# chmod 700 /usr/local/sbin/setsebool_insmod.sh

  1. Create a systemd unit file that runs the above script after the system has booted, /etc/systemd/system/setsebool_insmod.service :

Description=Enable SELinux boolean secure_mode_insmod



  1. Set permissions on the systemd unit file:

[root@localhost ~]# chmod 644 /etc/systemd/system/setsebool_insmod.service

  1. Reload the systemd process to discover our new service:

[root@localhost ~]# systemctl daemon-reload

  1. Enable the service to start after reboot:
    [root@localhost ~]# systemctl enable setsebool_insmod.service
    Created symlink /etc/systemd/system/default.target.wants/setsebool_insmod.service

  2. Ensure that the boolean is set to “false”, start the service and ensure that the boolean is now “true”:
    [root@localhost ~]# getsebool secure_mode_insmod secure_mode_insmod --> off [root@localhost ~]# systemctl start setsebool_insmod.service
    [root@localhost ~]# getsebool secure_mode_insmod
    secure_mode_insmod --> on
    [root@localhost ~]#

  3. Reenable the /etc/fstab line that mounts /boot/efi

  4. Reboot the system.

  5. Ensure that the boolean is set to true:
    [root@localhost ~]# getsebool secure_mode_insmod
    secure_mode_insmod --> on
    [root@localhost ~]#

Note: you might want to start the service in an earlier target than default, but at least this works.