[systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?

[Felix Rubio]

Just to close this off, because you guys have spend time in helping me 
navigate through this: Finally I decided to go for FDE based on the TPM. 
Then, most of my concerns where addressed by using PCRs 0,1,7 and 9, so 
that initramfs gets also measured. This allows me to keep a separate 
boot partition, and to not get involved yet with UKI.

Now I am trying to work out a way to smooth the case when after a kernel 
/ modules update the TPM state changes and will not unlock 
automatically... but this for another day, I guess :-)

Thank you very much for you help!

-- 
Felix Rubio
"Don't believe what you're told. Double check."

On 2023-05-27 08:31, Felix Rubio wrote:
> Hi Lennart,
> 
> I remember having read some time ago that UKI could pose problems with
> early-boot modules provided by vendors and so. But... let's give it a
> try! Then, the process should be:
> 
> 1. Install a version of shim signed with MS keys.
> 2. Generate the UKI
> 3. rename the UKI image to grubx64.efi so that it gets picked up by 
> shim
> 
> As a side: the ESP partition is bit small. Do you think if I introduce
> systemd-boot I could load the UKI being stored from /boot? In that
> case this would be like
> 
> 1. Install a version of shim signed with MS keys.
> 2. Install systemd-boot as grubx64.efi so that it gets picked up by 
> shim
> 3. Generate the UKI to /boot/
> 
> I will give it a try... and see how it goes.
> 
> Regards!
> 
> --
> Felix Rubio
> "Don't believe what you're told. Double check."
> 
> 
> On 2023-05-25 10:26, Lennart Poettering wrote:
>> On Mi, 24.05.23 19:01, Felix Rubio (felix at kngnt.org) wrote:
>> 
>>> Hi Lennart,
>>> 
>>> "Sorry, but GPG is a no-go. Not in 2023."
>>> 
>>> Yes, I understand that. What I am trying to get is a simple way to 
>>> verify
>>> that the initramfs has not been tampered with. UKI comes with its own
>>> challenges, using encryption tied to a measured boot looks overkill, 
>>> and I
>>> fully agree in which adding an authentication layer is not
>>> desirable.
>> 
>> I am not sure what "challenges" you specifically have in mind, but a
>> UKI with an initrd in a PE envelope (i.e. the "add-on" concept I
>> mentioned), then you should be pretty close to current behaviour, no?
>> 
>>> Then... what alternatives are available for just performing 
>>> verification of
>>> the initramfs? I was giving a look at IMA now, so this could be 
>>> sorted with
>>> a policy... but I think this is not supported in sd-boot.
>> 
>> IMA verifies files after the kernel is up, not before. It's not
>> suitable for validating initrds.
>> 
>> Anway, you should really ask yourself what cryptographic key you want
>> to authenticate against. Local or vendor one, and where shall it be
>> stored. That dictates your choices more than anything else.
>> 
>>> In the case I wrap the initramfs on a PE envelope, as you suggested, 
>>> when
>>> then its signature be validated automatically? when it gets loaded? 
>>> Because,
>>> if so... this would work enough for this use case.
>> 
>> In the "add-on" module for UKIs I mentioned the validation of both the
>> UKI and the add-ons are done via regular UEFI SecureBoot or via
>> shim. Both UKIs and add-ons are just PE files after all that thus can
>> be verified that way. Because the files can be authenticated via shim
>> you get MOK and so on.
>> 
>> Lennart
>> 
>> --
>> Lennart Poettering, Berlin