Re: secure boot

[kiasoc5 <kiasoc5@disroot.org>]

Hi Antonio,

On Sat, 2022-08-20 at 13:23 +0200, Antonio Carlos Padoan Junior wrote:
> As far as I understand, Guix doesn't provide means to automatically
> sign
> bootloaders and kernels in order to use UEFI secure boot after each
> system
> reconfigure (assuming a PKI is properly implemented).  Hence, using
> secure boot with Guix is currently not viable (am i correct?).

Guix has sbsigntools packaged so you may sign Grub itself after each
system reconfigure. But signing only Grub is not enough, because Grub
does not yet validate the secure boot signatures of the kernel and
initramfs. So we currently do not have 100% secure boot.

We should make sure all files used in the boot process are signed. This
includes, the bootloader itself, the configuration file, the kernel
binary, and the initramfs [1].

One way to do this is to boot an signed efistub containing all of the
files that need to be verified. You could boot efistub directly
via UEFI, use systemd-boot/gummiboot, or have Grub chainload an EFI.
Guix doesn't support gummiboot/EFI chainloading yet, so efistub through
UEFI seems the easiest. You would create an efistub, add it to efi
partition, sign it, and add it to UEFI with efibootmgr with each
system reconfigure. This removes the need for GRUB since each efistub
would boot the correct system generation, although the efi partition
would need to be cleaned occasionally since efistubs do take up disk
space.

Another way is to sign the bootloader with secure boot keys, and then
sign the initramfs, kernel, and config with GPG keys [2]. This seems
easier to achieve with current Guix tooling.

Automating these processes might be tricky because we have to avoid
putting keys for secure boot in the store since it's world-readable.

For reference NixOS has not officially implemented secure boot either.
Their current progress afaik is they are working on bootspec, "a set of
memoized facts about a system's closure." This would enable them to
support secure boot more easily later [3,4].

> In this context, can I assume that the risk of not having secure boot
> is
> minimized by the fact that in each system reconfiguration, the early
> boot chain is overwritten is such a way that, if a malicious is
> introduced somehow, it will be also overwritten? Am I correct?

Secure boot concerns the evil maid attack, which affects the bootloader
and efi system partition. I'm not sure which parts of the boot chain
are overwritten during system reconfigure, but in any case you must
boot the system to reconfigure. If you don't have secure boot, then you
have no protection against loading maliciously implanted boot
executables.

> In addition, how much more difficult it is to introduce such
> malicious
> code in a Guix system giving its functional approach and store
> system?
> (in comparison with others Linux distributions).

Assuming one doesn't have root, they could modify code inside any .scm
files you are using (system generation, profiles, etc) to put files in
the store next time you run a Guix command that modifies the store. Of
course, they have to get into your system first. This is the only attack
I could think of.

> I know that Guix provides an amazing approach to secure software
> supply
> chain, but I as wondering if not having secure boot can be considered
> a major drawback for Guix.

If evil maid is in your threat model then I would not run an OS that
does not have secure boot. You can still run Guix package manager on a
Linux that does support secure boot (eg Parabola). That being said many
great OSes such as the BSDs do not support secure boot so I don't
think it's a major drawback.

1. https://git.alpinelinux.org/aports/tree/main/gummiboot/APKBUILD
2. https://libreboot.org/docs/gnulinux/grub_hardening.html
3. https://github.com/NixOS/rfcs/pull/125
4. https://github.com/grahamc/rfcs/blob/bootspec/rfcs/0125-bootspec.md