Nixos-install with custom flake results in /boot being world accessible

Help
1

Hey guys, so I’m working on my custom NixOS config and I’m installing NixOS with the config but I get this warning after I finish running nixos-install

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

I have no idea why it’s doing this since I haven’t changed any of the filesystem partitioning options. Anyone know how to fix this? Here’s the repo here: GitHub - NovaViper/NixConfig

2

what’s /etc/fstab say? Perhaps the permissions are off? check the permissions of /boot in general?

3

My fstab is like this (this one is pulled from the desktop)

# This is a generated file.  Do not edit!
#
# To make changes, edit the fileSystems and swapDevices NixOS options
# in your /etc/nixos/configuration.nix file.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>

# Filesystems.
/dev/disk/by-uuid/88c5f974-bde5-4b5b-8f1a-085e625bfb78 / ext4 x-initrd.mount 0 1
/dev/disk/by-uuid/DEA8-6959 /boot vfat defaults 0 2


# Swap devices.
/swapfile none swap defaults

And the permissions for /boot is this

❯ ls -al /
...
drwxr-xr-x   - root 31 Dec  1969  boot


❯ ls -al /boot
drwxr-xr-x - root 26 Sep 00:05  EFI
drwxr-xr-x - root 21 Oct 21:59  loader
4

strange, is root the owner and group? or is that - just obscuration?

1 Like
5

:thinking: That’s… really odd, it’s suppose to be the owner and the group. I didn’t tell it any other way to configure

6

Also, I did find a sort of solution but doesn’t explain why NixOS doesn’t set these permissions up properly by default. I had to declare options for the filesystem and it made it work

    "/boot" = {
      device = "${bootPart}";
      fsType = "vfat";
      options = [ "fmask=0077" "dmask=0077" "defaults" ];
    };
7

I’ve never seen anyone else need those settings. You seem to be on a very recent unstable, maybe a regression?

8

I’m thinking the same but I’m unsure of which particular unstable commit in particular would’ve resulted in this change. I’m going to try and do some testing with the commit versions and see which commit date in particular breaks it

9

I’ve never seen those options in use either, and it does seem odd but glad you found a workaround.

10

:confused: Even odder now, I went ahead and reinstalled the system again with the flake to test for a different issue, and even with those mount options declared, I got that same error again. Even the fstab includes the new options I added.

–Edit–
Quick thing I noticed also, I restarted the machine after the install, and those mount options went and set the permissions correctly.

1 Like
11

They wouldn’t have taken effect until the fs was next mounted, yeah.

But actually I think the issue is that somehow the filesystem was mounted under a different user and wasn’t owned by root. vfat will normally assume the user doing the mount is the owner. I don’t have a suggestion for how this happened, other than some vague handwavy noises about temporary uid’s for build. An ls -n might have been interesting when it was printing that weird -, but I’d expect a number for any user that wasn’t known. Do you have a - user in passwd, by any chance?

I would also take a look at the ownership and permissions (and maybe contents) of the underlying /boot in the root filesystem (i.e. when the EFI isn’t mounted over the top of it). It should be fine to just umount it while running, temporarily.

Edit: the warning was almost certainly just the result of string comparison ("-" != "root"), rather than acutal permissions, and we need to figure out why that’s happening.

1 Like
12

I wonder if it’s related to me using sudo whenever I’m creating, formatting, and mounting the partitions in the iso? Because in the disks.nix file for both systems, the scripts all include sudo since the commands seem to only function properly on the iso when I run them with sudo.

Here’s the boot folder when I unmounted the EFI from it (taken from the desktop since it too is having the same issue as the laptop).

❯ sudo ls -alns /
total 16777300
       4 drwxr-xr-x   2 0 0        4096 Sep 25 23:28 boot

❯ sudo ls -als /
total 16777300
       4 drwxr-xr-x   2 root root        4096 Sep 25 23:28 boot

And no, I don’t have a - user.

13

I’m so curious where this - came from and my Google fu isn’t strong enough and my duckduckgo searches are also coming up empty.

14

This is because of the update to systemd 254. It now emits this warning when the random-seed file is world readable, which it would be by default with vfat. Yes, the fix is to add umask=0077 (or, equivalently, fmask=0077 and dmask=0077) to the mount options. This is what systemd-gpt-auto-generator does, for example. We didn’t end up adding anything to NixOS to add those options automatically because there are some awkward edge cases that make it not so trivial. And the warning should only come up when doing something that has to do with the random-seed, such as the initial install.

3 Likes
15

Ah that explains it. :thinking: Perhaps a warning about not including those options when installing NixOS manually with nixos-install? Just so others wouldn’t be confused when seeing that warning that systemd produces.

1 Like
16

Thanks for creating this post and thanks to the knowledgeable people who have responded.

I agree with adding a warning or some kind of notification.

Like you, I got this error message after (re)installing NixOS. After rebooting, however, my /boot directory is correctly owned by root. If I’m following this thread correctly, these corrected permissions mean that there’s not a persistent security hole.

I’m sure others like us will see this error message and panic a little at first until they find this thread or until an explanation is added to the installation process. :sweat_smile: So adding that notification is a great idea.

1 Like