5

according to https://wiki.ubuntu.com/UEFI/SecureBoot Initrd images are not validated. Is this information up to date? this would make the whole secure boot totally useless as an attacker could very easily replace initramfs with a one that logs LUKS password and sends it to him... This in turn would make all the module signing hassle and disabling hibernation on secure boot totally ridiculous.

if it's indeed so, is there any launchpad bug/feature-request that we can upvote to make secure boot actually secure?

OTOH, if this statement is obsolete, how does the verification work? where is the key pair that is used to sign initrd files when they are generated during new kernel installations? which component later verifies the signature? (shim, MOK, GRUB, kernel itself?) ...or maybe PCRs and TPM are somehow used instead?
...and how about the kernel command line? this one must be signed/verified also to make the boot secure...

2
  • @snaker I somehow have a feeling that you may have some clue regarding this ;-)
    – morgwai
    Jun 7 '20 at 8:53
  • The ability to vote on bug trackers is merely a tool to reduce me too!-style distractions. To get things adopted in the main Ubuntu repositories you should instead be demonstrating that the thing you want a) works and b) has some merit.
    – anx
    Jun 7 '20 at 10:23
1

You do not even need to sign/verify the initramfs, because you do not need to keep it accessible (unenencrypted on a local disk).

Ubuntu 20.04 is perfectly capable of dealing with an installation layout where the initrd file is contained inside an encrypted container (currently works for luks1 on AMD64 & ARM64, luks2 and more platforms in future versions). Other than downgrading to the earliest version with identical kernel, nobody but you could modify the initrd sealed with your password.

The part that is really missing in current automation is the generation of a signed grub binary that verifies its own configuration. It works out of the box too - grub can verify gpg-style signatures - but the kernel install scripts shipped by Canonical do not setup/update that in the usual fully automatic fashion.

If you wanted to to configure a fully verified boot chain in current Ubuntu releases, you might try to place your own script (which gpg --signs your config, then integrates that into the grub binary using grub-mkstandalone then sbsigns that binary before placing it into /boot/efi) into /etc/kernel/postinst.d/ to have it automatically called whenever your install/remove a kernel (version).

Note that almost no consumer PC is actually used to enroll custom keys for secure boot (MOK), so you will likely run into some firmware bugs. You will not find too many bug reports about this topic either, simply because few people want/do such a complicated and error-prone thing.

And this is just the Ubuntu side of things. You probably win nothing in terms of security (but you are welcome to contribute there).

3
  • does it mean in that in 20.04 displaying password prompt and actually unlocking luks device is handled by GRUB as opposed to scripts on initramfs as before? (I'm on 18.04 still). Thanks!
    – morgwai
    Jun 7 '20 at 11:40
  • @morgwai no, that is just one of the possible setups that is correctly handled by the support scripts (initramfs-tools, grub) - it is not the default disk layout.
    – anx
    Jun 7 '20 at 12:26
  • @anx When you put the initramfs an encrypted container this means there can not be any automated unlocking (for example with clevis/tag). Am I missing something? May 11 at 12:09
0

You might need to define a threat model first: what are you trying to protect against?

Secure Boot should prevent even the root user from breaking the integrity of code that runs at kernel-level privilege. This is most obvious at boot: even root should not be able to install a kernel or bootloader that isn't trustworthy, and we use signatures to determine trustworthiness. However, it also extends to the running kernel: Ubuntu kernels will detect secure-boot and enter lockdown integrity mode early in boot. Integrity mode attempts to maintain that security boundary between root and the kernel at runtime. (This stops you doing something like kexec-ing from a trusted kernel to an untrusted one.)

Something that has never been part of the secure boot mission is protecting against root replacing non-kernel binaries. This is a reasonably difficult problem and scripting languages make it even harder. It's even more fraught in the FOSS world because people get very irate at anything they perceive to be limiting software freedom, even if it's possible to disable. (See, for example, what Apple does with signing basically everything!)

There are definitely ways to restrict root installing malicious binaries. You can use grub's detached signature support to require that the initrd is signed. But then everything, even grub.cfg, has to be signed, and that would get really irritating to administer. You could use something like dm-verity. IMA could help you (but not so much for scripts). But you very quickly stop having a general purpose system!

1
  • > has never been part of the secure boot mission is protecting against root replacing non-kernel binaries. Why can't then root change PK/KEK/db? SB does protect boot process from malicious root (think about privilege escalation) by requiring that someone be physically present during boot, who could approve the changes of the EFI variables.
    – DimanNe
    Apr 18 at 8:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.