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
