Re: Kernel with IMA and "better" secure boot / MOK support
On 2024-09-26 16:52, simon-b@murena.io wrote:
Hi,
Hi, thanks for replying! Just to avoid any confusion, the setup I'm using already works the way I want, I'm just hoping to find a way to avoid custom kernels.
you can add public keys to the kernel keyring which are stored in a hardware store (e.g. the UEFI key database). [0]
This is mostly what I've been doing, using mokutil to store the mok cert in an efivar with shim. shim then pulls them in to the MokListRT efivar, which the kernel then validates against (if I understood it all correctly). But that is only as long as IMA is enabled in the kernel.. without IMA the .machine keyring never gets populated. The MOK keys will however end up in the .platform keyring even without IMA, but it will not trust them since they're not part of the chain the kernel trusts (.builtin_trusted_keys, or .secondary_trusted_keys). One would need to add one's own CA cert in the kernel build (and sign the modules with the same CA to make this work, I think. Documentation has left me a bit confused on this.
You can also sign the modules with a MOK. [1]
I've also tried to do this, adding my MOK cert next to the Database cert from the UEFI secure boot setup, and then signing the the modules with the corresponding key. But the kernel still didn't want to trust this cert. Again I assume because the kernels chain of trust requires the MOK cert to come from the same CA as one of the .builtin_trusted_keys. Arch uses auto-generated keys on their kernel builds, so this can't work as far as I understand. And even they signed with their own keys, I'd need to sign my modules with the same key as them, which obviously wouldn't be possible. Perhaps there are facilities in the kernel I'm unaware of here but it seems to me the only way for a user to validate out-of-tree module signatures are with MOKs. Which is why I started thinking maybe there needs to be another official kernel that supports this.
Since I don't use external modules, I have not tested any of these methods.
Any modules that comes with the kernel will always pass validation and load since they share the same auto-generated key/cert.
I am not sure how you use the IMA (e.g. wether you verify the PCR10 from a TPM2), but an alternative could be
a dm-verity signed root-fs, e.g. created with verity-squash-root [2].
I believe the more advanced features of IMA are not needed in this scenario. In the case of being able to validate out-of-tree modules against MOK signatures all that is needed is CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT (as far as I can tell at least).
Best,
Simon
[0] https://www.kernel.org/doc/html/v6.11/admin-guide/module-signing.html
[1]
https://gist.github.com/lijikun/22be09ec9b178e745758a29c7a147cc9
[2]
Regards, Johan
September 26, 2024 at 12:09 PM, "Johan Dahlberg" <joda@nejomi.net> wrote:
For the last couple of years I've been rolling my own kernels on a couple of machines in order to have better support for secure boot and especially mok keys. This has been necessary for being able to boot with lockdown=confidentiality/integrity and still be able to load any signed out-of-tree (dkms) modules. The official kernels in arch is built without IMA support as it would break the ability to kexec to another kernel when secure boot is on (since the kernels are built with auto-generated keys, they would fail validation). There are some bug reports on the subject, see [1] and [2].
How I'm validating signed out-of-tree modules goes as following:
- uefi to setup mode
- create my own EFI keys, and enroll them
- roll my own uki kernel (built with IMA) and sign it and it's modules and any out-of-tree modules
- set uefi to boot shim.efi, which then calls grubx64.efi (which is just a renamed systemd-boot in my case)
- shim passes on mok keys
- systemd-boot boots the kernel with lockdown=confidentiality
- kernel adds the keys passed from shim to the (.machine) keyring and successfully loads any modules signed with a key listed in mok
It's been a while since I set it up so I might have misremembered some step there.
Anyway to my question, since the situation with kexec and IMA is probably not going to change, and since there probably (?) are more people out there who would like to use the whole secure boot chain with MOKs and all, perhaps it would be possible to discuss providing another official kernel which is built to support the above scenario? I'm not too deep into the arch dev system and tools, but considering what I'm doing - just pulling the PKGBUILD and doing some minimal changes to the config and then building it, it seems it would not add too much of a maintenance overhead.
Perhaps there are other ways of achieving the same results that I'm not aware of.. if so I'm curious to hear about it. Mostly I'm just trying to get out of having to use custom kernels. :-)
Thanks for reading,
Johan
participants (1)
-
Johan Dahlberg