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: Personal NixOS Config

1 Like
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.

7 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
17

Decided to switch to systemd-boot today* after this adventure and ran into this error. Not much on github (other than this issue) or the forum other than this thread.

Sounds like adding filesystems."/boot".options = [ "umask=0077" "defaults" ]; is the recommended fix?

EDIT: * for context this is on a zfs-root UEFI system previously using grub
EDIT2: Added "defaults", in keeping with the default value if options is omitted entirely

1 Like
18

Either that, or choose to ignore it - the warning is only emitted at install time and besides that its really a highly theoretical security issue it’s warning about…

1 Like
19

Hi!

Replying to @n8henrie, and also to future time travellers that end up here.

As you probably know, these boot options end up on /etc/fstab, which is a text file with I think six columns, separated by whitespace. The fourth field (fs_mntopts) declare the mount options for the filesystem in question. So, imagine that for a certain filesystem we don’t specify options. Then we end up with a line that has not six, but just five columns, and that breaks its parsing. That’s why the have the no-op “defaults”. But when we specify at least one mount option, such as “umask=0077”, the “defaults” keyword is redundant.

To verify that this is actually correct, you can just verify which mount options are active with the “mount” command, with and without the “defaults” keyword, on top of the specified ones.

This is a common misconception, that is not even properly clarified in the fstab(5) manpage, although if you piece together the relevant parts, it’s all there:

The fourth field (fs_mntops).
…
The usual convention is to use at least “defaults” keyword there.

(Which would hint that is needed).

Basic filesystem-independent options are:

   defaults
       use default options. The default depends on the kernel and the filesystem.
       mount(8) does not have any hardcoded set of default options.

(But this last paragraph hints the other way around).

The only reason I can come up with to justify having “defaults” around when other options are present is to simplify the scripts that create it (I’ve seen this over several distros over the years, if memory serves), but since this is clearly not the case in NixOS, I’d say we are better off without it.

Hope that it helps.

Happy hacking!

20

You mean /etc/fstab I assume?