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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx) 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



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux