NixOS with systemd-boot results in "security hole" warnings

[bjornfor]

Describe the bug

Since NixOS 23.11, using boot.loader.systemd-boot.enable = true; results in these warnings at bootloader install time:

⚠️ Mount point '/boot' which backs the random seed file is world accessible, which is a security hole! ⚠️
⚠️ Random seed file '/boot/loader/.#bootctlrandom-seedc878009c19a876dc' is world accessible, which is a security hole! ⚠️

(Minimal repro: sudo bootctl --esp-path=/mnt/boot install)

This happens when following the official NixOS installation manual (https://nixos.org/manual/nixos/stable/#sec-installation-manual-partitioning), which in particular says that for UEFI systems the ESP is to be created with mkfs.fat -F 32 -n boot /dev/sda3 and mounted with mount /dev/disk/by-label/boot /mnt/boot. Doing that makes files under /mnt/boot world readable, which apparently is a security hole.

I fixed the install time warning by mounting the ESP with sudo mount -o umask=007 /dev/sda3 /mnt/boot, but since nixos-generate-config doesn't pick up on mount options (at least not the umask= one), the installed OS still has the security hole and the warnings will be shown the next time the bootloader gets updated.

Manually adding the required umask= mount option in hardware-configuration.nix should permanently fix it.

Steps To Reproduce

Steps to reproduce the behavior:

1. Boot NixOS live medium in UEFI mode.
2. Follow installation manual: https://nixos.org/manual/nixos/stable/#sec-installation-manual-partitioning.
3. Set boot.loader.systemd-boot.enable = true; in configuration.nix.
4. Run nixos-install ... and see the mentioned warning.

Expected behavior

• Installation instructions don't result in a system with security holes.
• nixos-generate-config should probably pick up on umask= mount options, so that when the installation instructions get fixed the fix is also propagated to the installed OS.

Notify maintainers

Metadata

NixOS 23.11 (32f6357).

---

Add a 👍 reaction to issues you find important.

[crabdancing]

Since the expected workflow is to occasionally potentially using nixos-generate-config to overwrite hardware-configuration.nix when there's hardware/partition changes, I would recommend adding the setting to configuration.nix or another file instead. There's nothing to stop you from sticking this code wherever you want; Nix modules are automatically recursively merged.

  fileSystems."/boot" = {
    options =  [ "uid=0" "gid=0" "fmask=0077" "dmask=0077" ];
  };

But of course, this is just a workaround. Something like this should ideally be setup automatically.

[bjornfor]

options = [ "uid=0" "gid=0" "fmask=0077" "dmask=0077" ];

Why did you add all those options instead of just umask=007?

[crabdancing]

I really don't recall. It's just the fix that was in my system flake module for orchestrating boot processes. If umask is equivalent to fmask/dmask, then it makes sense to use that -- although I do tend to prefer to be explicit about user/group ownership wherever possible.

[eclairevoyant]

Worth noting that the ESP must be a FAT partition, which does not support permissions, so the only way to actually close the security hole would be to encrypt /boot, or put the random seed file elsewhere. The umask setting is simply silencing the warning without addressing the underlying limitations of FAT.

[crabdancing]

Ooof. That's a nasty footgun. Do you have any examples of NixOS configs that encrypt boot? I actually would be interested in doing that! It's useful for anti-tampering as well.

Also, for those who are interested, I can think of two other maybe-options:

• change permissions on /boot mount directory
• Deny access to entire process tree except root using a MAC like SELinux.

[bjornfor]

@eclairevoyant: I don't think you need to encrypt /boot, and a sufficient fix/workaround is posted above (change perms on the mount).

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/security-warning-when-installing-nixos-23-11/37636/3

[ElvishJerricco]

The umask setting is simply silencing the warning without addressing the underlying limitations of FAT.

@eclairevoyant No, not at all. It's true that it doesn't change any permissions on-disk, because FAT doesn't have permissions. But the only reason this is important is the first place is simply to keep non-root users from reading/writing the random-seed, which is accomplished with umask=0077. This is the intended solution upstream in systemd, as evidenced by the way systemd automounts the ESP.

You cannot encrypt the ESP or (reliably) use any other file system than FAT. UEFI includes protocols for accessing file systems that the firmware supports, which is how systemd-boot accesses /boot files. The UEFI spec only requires implementations to support plain FAT, so that's the only kind of storage you can reliably expect systemd-boot to work with. In practice, it often supports NTFS, and you can load custom file system drivers like those from efifs, but 1) This is not the intended design, and 2) I'm not aware of any encrypted storage drivers for UEFI.

[nrdxp]

I'm not aware of any encrypted storage drivers for UEFI.

FWIW, Grub does support encrypting the boot partition, for the hyper paranoid. I've done it before along with secureboot to prevent the possibility of an evil maid attack.

[ElvishJerricco]

@nrdxp To be clear, I was talking about UEFI drivers. You can add drivers for file systems in UEFI, e.g. with efifs, and I'm not aware of any such driver for encrypted storage. Yes, grub does have some LUKS support, but it's not great and I don't recommend it. To prevent evil maid attacks, you need secure boot, and you can use secure boot to verify the things on /boot instead of encrypting it (e.g. ukify, or lanzaboote).

[nrdxp]

To prevent evil maid attacks, you need secure boot

I'm aware, I also had secure boot setup on the system in question. I agree though grub's support is rather ad hoc, which is why I don't use it anymore

[bjornfor]

I made a fix at #300673. Can someone review please?