default file permissions on bootloader configuration

[Alexander Scheel]

CIS guidance for all distributions suggest securing grub bootloader configuration file permissions for two purposes:

1. In general, arbitrary users shouldn't have access to read grub configuration in general,
2. In specific, when a grub bootloader password is configured, we'd still prefer a principle of least-privilege, and prevent most users from having easy, ready access to the hashed password.

We suggest octal 0400 permissions for all systems, especially because we suggest bootloader passwords for level 2 compliance.

For some information, see for instance: https://workbench.cisecurity.org/sections/784579/recommendations/1284256

(CIS benchmark section 1.4.1; available for free though does require a free login).

There's two approaches I could see taken here:

1. Follow CIS by default and chmod to 400 after file creation,
2. Don't delete and recreate the file; instead, simply modify (truncate+write) to the correct contents.

The latter would make grub2-mkconfig aganostic of the actual CIS guidance, which perhaps might be a good thing.

Note that this is a bug in grub2-mkconfig as it explicitly sets a umask and chmod's conditionally based on password applicability (though, to a level not otherwise suitable for our purposes).

---

I am told the issue of overwriting permissions doesn't affect Fedora distributions and mostly impacts Ubuntu ones. This makes me suspect we either have an older version of grub2-mkconfig or some patches of our own.

[Julian Andres Klode (juliank)]

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.

[Julian Andres Klode (juliank)]

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

[Launchpad Janitor (janitor)]

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

[Alexander Scheel (cipherboy)]

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.

[Dimitri John Ledkov (xnox)]

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

[Launchpad Janitor (janitor)]

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

[Dimitri John Ledkov (xnox)]

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 ?

[Julian Andres Klode (juliank)]

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

[Julian Andres Klode (juliank)]

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