default file permissions on bootloader configuration

Fedora doesn't use grub-mkconfig after the initial install, but drops https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ files into directories, so it's not entirely surprising their behavior is different.

I'd say at the moment bootloader passwords are unsupported as IIRC, there are issues with keyboard not working correctly in a bunch of places. The use of them seems limited, given that you can just remove the config entry given physical/pre-boot access. And encrypted /boot, AFAICT, is also not supported.

Option 2 is a no go that might cause unbootable systems as you might end up with an empty file in a crash.

FWIW, we explicitly ship a patch to make the file world-readable if it does not contain a password.

From: Colin Watson <email address hidden>
Date: Mon, 13 Jan 2014 12:12:55 +0000
Subject: Make grub.cfg world-readable if it contains no passwords

Patch-Name: grub.cfg-400.patch
---
 util/grub-mkconfig.in | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
index 9f477ff..45cd4cc 100644
--- a/util/grub-mkconfig.in
+++ b/util/grub-mkconfig.in
@@ -276,6 +276,10 @@ for i in "${grub_mkconfig_dir}"/* ; do
   esac
 done

+if [ "x${grub_cfg}" != "x" ] && ! grep "^password" ${grub_cfg}.new >/dev/null; then
+ chmod 444 ${grub_cfg}.new || true
+fi

Status changed to 'Confirmed' because the bug affects multiple users.

A few things to add to this discussion:

> I'd say at the moment bootloader passwords are unsupported as IIRC, there are issues with keyboard not working correctly in a bunch of places.

Yeah, I think this isn't meant as a true security _control_ (certainly any matter of physical access yields many ways). But it is a defense-in-depth type measure that at least slows down someone with physical access. Definitely agree things like Bluetooth keyboards will probably never work.

Another way of looking at it is a permission separation model where, e.g., a legitimate employee might not have access to change bootloader on their own machine (think: corporate managed device) whereas someone in IT might.

To clarify further, we also recommend the use of --unrestricted, whereby password is only required for modifying configuration and not booting at all.

The CIS community also generally feels that other parameters in there might be relevant to protect, hence the suggestion to chmod 400 all the time, rather than conditionally based on password.

From that context, in my mind, I think that this still justifies the permission changes by default and not chmod back to 444 without a password being present.

we currently do chain grub.cfg from ESP to boot partition, can the password be set in that grub.cfg file instead? which today is outside of the scope of grub-mkconfig management.

And that grub is protected with restrictive mount options of ESP, see /boot/efi/EFI/ubuntu/grub.cfg

This bug was fixed in the package grub2 - 2.04-1ubuntu47

---------------
grub2 (2.04-1ubuntu47) impish; urgency=medium

  * Drop grub.cfg-400.patch (LP: #1933826)

 -- Julian Andres Klode <email address hidden> Thu, 02 Sep 2021 14:37:43 +0200

I am still confused how 400 permission for grub.cfg can work at all.

Depending on the upstream grub version, it either cats things to it, or moves a new file to it. In both cases, either permissions reset to 600 or write is not allowed at all. Or one has custom/distro/downstream patched grub that does something different.

Are you inspecting grub.cfg which is stored on non-posix filesystems with restrictive mount umask set? I.e. grub.cfg stored on ESP mounted with fmask=0022,dmask=0022 ?

So we actually have 0600 at the moment after dropping the patch.

I think 600 is enough here, and that's what we do in 2.12~rc1 and upcoming versions as I dropped the patch.