Re: why systemd-boot (seems as everyone else) does not check the signatures of initramfs?

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On Wed, May 24, 2023 at 1:22 PM Felix Rubio <felix@xxxxxxxxx> wrote:
>
> Hi Andrei,
>
> Thank you for correcting my statement about Grub2, I did not know that.
>
> I agree that having a measured boot, that decrypts the system is a
> better solution... but this is, correct me if wrong, still very green:
> There are some approaches supported, but none of them seems to be
> structural: they rely on the existence of a TPM, introduce additional
> dependencies on the update process (when the kernel/initramfs changes
> the previous measurement will not be correct anymore and needs to be
> updated), etc. On the other hand UKI comes with its own challenges, and
> also forces the admin to rebuild the UKI any time there is an update.
>
> I feel there should be some middle point in which we do not have to rely
> on a TPM and a fully measured system, but we can still make sure that
> the initramfs is trusted. The question, then, is: Is this something that
> could be supported in systemd-boot, or this is something that is
> considered to be just out of scope?
>

Secure Boot defines signatures for executable PE files. To apply it to
initrd one would need to either wrap it in PE (which is effectively
what UKI does) or develop a new standard for attaching signature to
initrd. For example, using grub2 GPG keys :)

> Thank you
>
> ---
> Felix Rubio
> "Don't believe what you're told. Double check."
>
> On 2023-05-23 21:32, Andrei Borzenkov wrote:
> > On 23.05.2023 21:54, Felix Rubio wrote:
> >> Hi everybody,
> >>
> >> I am trying to understand something, and after looking around I have
> >> not
> >> found any explicit answer. Maybe somebody in this list can shed some
> >> light on the matter? I have a laptop in which I am setting up the boot
> >> process through systemd-boot, and this works. Now, I'd like to give a
> >> try to enable Secure Boot so that the whole boot sequence is protected
> >> against tampering. As I am still learning about the technology, I
> >> prefer
> >> to land on the use of shim/MOK. For what I have read, the sequence
> >> should be:
> >>
> >> 1. Install a version of shim signed with MS keys.
> >> 2. On that same folder copy systemd-bootx64.efi, renamed to
> >> grubx64.efi
> >> (as shim seems to work only with Grub as 2nd stage loader).
> >> 3. Sign the kernel with the key for which the certificate has been
> >> enrolled in MOK.
> >> 4. Reboot, enroll the keys and... voila.
> >>
> >> So far, so good... until we hit the initramfs wall: the efi's and
> >> kernel
> >> signatures are verified, but not that of the initramfs. I have seen
> >> that
> >> grub2 does not do it (it relies in GPG signatures, in which seems to
> >> be
> >> a workaround), and I have not found any place stating that
> >> systemd-boot
> >
> > GPG is independent alternative method of verifying files and most
> > certainly not a workaround (it was implemented in grub2 long before
> > Secure Boot support).
> >
> >> does it. I have seen however, some steering towards the use of UKI...
> >> but this comes with its own problems about out-of-tree kernel modules
> >> and so.
> >>
> >> So, the question is: why the kernel image gets verified but not the
> >> initramfs? Is this mandated by some standard, or is an engineering
> >> decision?
> >>
> >
> > Kernel image has verifiable origin (it is signed by the same entity
> > that provides your distribution). It is static and does not change on
> > end user system which makes it possible to sign by maintainers of
> > distribution by a secret key that is hopefully kept secret.
> >
> > initrd is volatile, it is usually generated on the same system where
> > it should be verified which means the key to sign it must be kept on
> > the same system as well. Which makes it more probable that secret key
> > will be leaked if system is compromised. And leaked secret key allows
> > installing an arbitrary malware as part of initrd.
> >
> > Measured boot does not have this problem. If you encrypt your root and
> > only allow decrypting if initrd (and kernel and any other data used
> > during boot) has known content then initrd will be implicitly verified
> > and if it is changed system simply fails to boot. This does not
> > require any key management or storing any persistent secret on end
> > system. Downside is that it requires TPM (or some other tamper
> > resistant way to store hashes) so not universally applicable.
> >
> >> Thank you very much!
> >>