Secure boot support?
It shows up as UEFI but it doesn't boot without the proper signatures. Any ETA? Sent with [Proton Mail](https://proton.me/) secure email.
Re: secure boot
On 24-08-2022 05:07, Philip McGrath wrote: I could imagine a process like this: 1. Build the binary that needs to be signed. 2. Outside of the Guix build environment, create a detached signature for the binary using your secret key. 3. Add the detached signature to the Guix store, perhaps with 'local-file'. 4. Use Guix to attach the signature to the built binary. 5. Use the signed binary in your operating-system configuration. To implement this, you could have a look at "dynamic dependencies" in guix/store.scm and guix/graftsscm. From the with-build-handler docstring: Build handlers are useful to announce a build plan with 'show-what-to-build' and to implement dry runs (by not invoking CONTINUE) in a way that gracefully deals with \"dynamic dependencies\" such as grafts---derivations that depend on the build output of a previous derivation." On grafts: the derivation of the grafted version depend on what the references of the store item used to be, this can only be decided outside the store (kind of similar to this situation). Greeetings, Maxime OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: secure boot
On Sun, Aug 21, 2022, at 4:46 AM, Josselin Poiret wrote: > Hi Antonio, > > Antonio Carlos Padoan Junior writes: > >> 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?). > > You're right, we don't really have any means to do that. It would have > to be done outside of the store, again, so that the private key doesn't > leak into it. > I could imagine a process like this: 1. Build the binary that needs to be signed. 2. Outside of the Guix build environment, create a detached signature for the binary using your secret key. 3. Add the detached signature to the Guix store, perhaps with 'local-file'. 4. Use Guix to attach the signature to the built binary. 5. Use the signed binary in your operating-system configuration. IIUC, executables that run in the UEFI environment need "secure boot" signatures to be attached, but you may be able to use detached signatures directly for other things that they want to verify by means other than "secure boot". I expect the things that need to be signed are small, build reproducibly, and change rarely, which might make this especially practical. -Philip
Re: secure boot
Josselin Poiret writes: Hi Josselin, > It's not an easy problem unfortunately, and the number of people whose > threat model requires such a thing is slim, hence the lack of work in > that direction. that sounds fair. Thanks for the explanation, it was clear! Best regards, -- Antonio Carlos PADOAN JUNIOR GPG fingerprint: 243F 237F 2DD3 4DCA 4EA3 1341 2481 90F9 B421 A6C9
Re: secure boot
Hi Antonio, Antonio Carlos Padoan Junior writes: > Can we imagine signing the kernel outside the guix layer, I mean, > directly into the store without using guix commands? I understand this > would break conceptually the Guix functional characterization, and it is > not very "clean". But despite these points, any other side effects expected? This subject has been discussed a bit in the past. My opinion on what you're suggesting is that: * We should not modify the store in place. This is bound to create problems for the user, because we'd be breaking the Guix guarantees. * You could sign it out of the store. Basically, something like `sign /gnu/store/xx-bzImage > /boot/bzImage_signed`. However, this poses problems with generations, since either we prohibit loading older generations, which is a huge step backwards, or we sign all of the older generations as well, which will take a non-negligible amount of space. In that case, we'd also need to keep track of the different signed kernels that are sitting in /boot to be able to clean them up when the generations are deleted. It's not an easy problem unfortunately, and the number of people whose threat model requires such a thing is slim, hence the lack of work in that direction. Best, -- Josselin Poiret
Re: secure boot
Thank you for your answer! Josselin Poiret writes: > Hi Antonio, > > Antonio Carlos Padoan Junior writes: > >> 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?). > > You're right, we don't really have any means to do that. It would have > to be done outside of the store, again, so that the private key doesn't > leak into it. > Can we imagine signing the kernel outside the guix layer, I mean, directly into the store without using guix commands? I understand this would break conceptually the Guix functional characterization, and it is not very "clean". But despite these points, any other side effects expected? I'm not sure if my question is convenient for this list, if it is not, sorry for the inconvenience. Best regards, -- Antonio Carlos PADOAN JUNIOR GPG fingerprint: 243F 237F 2DD3 4DCA 4EA3 1341 2481 90F9 B421 A6C9
Re: secure boot
Hi Antonio, Antonio Carlos Padoan Junior writes: > 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?). You're right, we don't really have any means to do that. It would have to be done outside of the store, again, so that the private key doesn't leak into it. > 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? A reconfigure would overwrite the bootloader, and most likely create a new system generation with bootloader configuration. > 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). Nothing is stopping an attacker from overwriting your bootloader with their own, which could load a kernel of their choosing. They would need to be able to boot off something though. And once you're compromised that way, I don't think you could consider running `guix system reconfigure` an option. Best, -- Josselin Poiret
Re: secure boot
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
Re: secure boot
That would be interesting, even on a Talos II, which has owner controlled secure boot. There will be no need to sign with a Microsoft key as most UEFI implementations do. There are two Microsoft keys, one for Windows and one for all other OSes. On Sat, 2022-08-20 at 13:23 +0200, Antonio Carlos Padoan Junior wrote: > Hello, > > I hope my question makes sense. It concerns Guix grub UEFI > bootloaders. > > I would like to understand in which extent Guix functional approach > helps to secure the computer with regards to an early boot malicious > code/malware infection. > > 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?). > > 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? > > 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). > > 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. > > Best regards
secure boot
Hello, I hope my question makes sense. It concerns Guix grub UEFI bootloaders. I would like to understand in which extent Guix functional approach helps to secure the computer with regards to an early boot malicious code/malware infection. 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?). 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? 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). 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. Best regards -- Antonio Carlos PADOAN JUNIOR GPG fingerprint: 243F 237F 2DD3 4DCA 4EA3 1341 2481 90F9 B421 A6C9
Re: Fun question: has anyone tried secure boot with GuixSD?
Thanks for asking others to leave the "Microsoft-phobia" aside. This is important because we must replace our (organization/brand)-based view with a per (product/project/model/work)-based view, because exclusively for-profit organizations aren't always in favor of the free/libre software movement (according to [[https://k7r.eu/there-is-no-free-software-company-but/]] and [[https://media.libreplanet.org/u/libreplanet/m/libreplanet-2016-the-last-lighthouse-3d51/]]). Before anyone else jumps at us, it's important to note the difference between "Secure Boot" and "Restricted Boot". Basically, the first one allows the user himself to manage (add/remove/modify) any keys or trust levels he wants to, while the second doesn't ([[https://media.libreplanet.org/u/libby/m/embracing-secure-boot-and-rejecting-restricted-boot-matthew-garrett/]]). -- - [[https://libreplanet.org/wiki/User:Adfeno]] - Palestrante e consultor sobre /software/ livre (não confundir com gratis). - "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard que está no endereço acima aos teus contatos. - Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu aceito, mas não repasso. Entrego apenas em formatos favoráveis ao /software/ livre. Favor entrar em contato em caso de dúvida.
Fun question: has anyone tried secure boot with GuixSD?
Following some interesting points I got during a discussion we had (offline), I have some questions for multiple projects. One of the topics is "Secure Boot". Apparently I missed the point with my hardware and systems where Secure Boot practically became mandatory and default. Which was a long time ago as I learned today. As you know or don't know I'm working towards a system based on GuixSD where one of its scenarios and configurations is to be used from an USB disk (think 'TAILS' big sister). I'm about to ask the secure-os mailinglist about how they handle the Secure Boot (ie: Microsoft) case with their systems. For us (as in us->Guix) I pose the questions: - has someone tried this? - would it technically be possible given the (un/likely) case we get Microsoft to cooperate (leaving aside the techno-ethical points for this question)? -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
