secure boot

secure boot

[Antonio Carlos Padoan Junior]

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: secure boot

[Tobias Platen]

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

Re: secure boot

[kiasoc5]

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

[Josselin Poiret]

Hi Antonio,

Antonio Carlos Padoan Junior <acpadoanjr@yahoo.com.br> 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

[Antonio Carlos Padoan Junior]

Thank you for your answer!


Josselin Poiret <dev@jpoiret.xyz> writes:

> Hi Antonio,
>
> Antonio Carlos Padoan Junior <acpadoanjr@yahoo.com.br> 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

[Josselin Poiret]

Hi Antonio,

Antonio Carlos Padoan Junior <acpadoanjr@yahoo.com.br> 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/xxxxxx-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

[Antonio Carlos Padoan Junior]

Josselin Poiret <dev@jpoiret.xyz> 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

[Philip McGrath]

On Sun, Aug 21, 2022, at 4:46 AM, Josselin Poiret wrote:
> Hi Antonio,
>
> Antonio Carlos Padoan Junior <acpadoanjr@yahoo.com.br> 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

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 1152 bytes --]


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


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]