vfat added to dev-sec.conf, but efi is used

[stndrf]

On my Debian 10 Server the EFI detection the task file modprobe.yml doesn't work:

root@mailsv001:~# df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  958M     0  958M   0% /dev
tmpfs          tmpfs     195M  2.9M  192M   2% /run
/dev/sda1      ext4       19G  1.4G   17G   8% /
tmpfs          tmpfs     974M     0  974M   0% /dev/shm
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs     974M     0  974M   0% /sys/fs/cgroup
/dev/sda15     vfat      121M  130K  120M   1% /boot/efi
tmpfs          tmpfs     195M     0  195M   0% /run/user/0

The task checks for /sys/firmware/efi, but the content of that folder is:

root@mailsv001:~# ls -la /sys/firmware/
total 0
drwxr-xr-x  6 root root 0 Aug  5 01:02 .
dr-xr-xr-x 13 root root 0 Aug  5 00:59 ..
drwxr-xr-x  5 root root 0 Aug  5 00:59 acpi
drwxr-xr-x  4 root root 0 Aug  5 01:02 dmi
drwxr-xr-x  9 root root 0 Aug  5 01:02 memmap
drwxr-xr-x  4 root root 0 Aug  5 00:59 qemu_fw_cfg

so this role doesn't detect that EFI is used and remove vfat and this results in the server not booting anymore.

[stndrf]

Workaround i used is adding vfat to the os_filesystem_whitelist

[schurzi]

very courius, I did some googling an even the Debian Docs mention, that cheking for /sys/firmware/efi is the telltale sign of being bootet in UEFI mode. (https://wiki.debian.org/UEFI#How_to_tell_if_you.27ve_booted_via_UEFI)

another way would be to do a dmesg | grep -i efi. Maybe you have an UEFI system, that is bootet in BIOS mode but was installed in UEFI mode? That could explain why there is a /boot/efi mountpoint.

[stndrf]

I'm also checked the docs and other sources, all say the /sys/firmware/efi check should be used.

$ sudo dmesg | grep -i efi
[    0.027692] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns

I use a vserver at Hetzner and i'm currently not sure what they are doing over there.

[danielkubat]

same issue with official CentOS/RHEL images in Azure, which are using vfat filesystem to mount /boot/efi.

cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

ls -la /sys/firmware/
total 0
drwxr-xr-x.  6 root root 0 Aug  5 11:24 .
dr-xr-xr-x. 13 root root 0 Aug  5 10:55 ..
drwxr-xr-x.  5 root root 0 Aug  5 11:24 acpi
drwxr-xr-x.  4 root root 0 Aug  5 11:24 dmi
drwxr-xr-x.  9 root root 0 Aug  5 11:24 memmap
drwxr-xr-x.  2 root root 0 Aug  5 11:24 qemu_fw_cfg
[centos@sj176-cent7-old ~]$ cat /etc/fstab

fstab:
UUID=05C1-ADF9          /boot/efi               vfat    defaults,uid=0,gid=0,umask=0077,shortname=winnt 0 0

therefore condition: https://github.com/dev-sec/ansible-os-hardening/blob/fe7e37e6e9bc0fd3b774979f3f3debe8ca387c1e/tasks/modprobe.yml#L15

is not triggered, because efi folder is missing and vfat filesystem is then not-whitelisted.

[schurzi]

we could check, that the corresponding fstab entry for /boot/efi exists, but that would feel like a very ugly workaround.

The other solution could be to remove the /boot/efi mountpoint from fstab when no efi is detected. I think, I would prefer this way.

Can one of you verify, that the systems still boot, when the fstab entry is commented?

[danielkubat]

For Azure Cloud compatibility with this hardening framework, you need to whitelist following:

vfat filesystem to mount /boot/efi
udf filesystem to mount /dev/sr0

therefore set os_filesystem_whitelist: [vfat, udf] as variable.

[schurzi]

I prepared a PR to check for this condition.

As for udf filesystem, I do not think, that this should be included. Since mounting CDs is relatively rare nowadays.

[danielkubat]

I prepared a PR to check for this condition.

As for udf filesystem, I do not think, that this should be included. Since mounting CDs is relatively rare nowadays.

great job with the PR. Regarding udf fs, I agree and just want to keep it described here for other Azure users.

[schurzi]

PR is merged now, so this should be fixed.