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

[Felix Rubio]

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?

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!
>>