On 2024-09-26 16:52, simon-b@xxxxxxxxx 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]
https://aur.archlinux.org/packages/verity-squash-root
Regards,
Johan
September 26, 2024 at 12:09 PM, "Johan Dahlberg" <joda@xxxxxxxxxx>
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
[1] https://bugs.archlinux.org/task/75102
[2] https://bugs.archlinux.org/task/75041
