Support linux keyring for kernel module signing about sbctl HOT 23 OPEN

That'd be a great feature to have; missing signatures for the virtualbox modules are the one reason I have to disable lockdown=integrty on some of my systems 🙂

from sbctl.

Isn't this important for lockdown=integrity in the equal measure?.. Which is the default when SB is enabled.

from sbctl.

I don't think integrity disallows loading of unsigned modules, so not as important I reckon. I'm unsure if the UEFI keys gets loaded into the keyring with ìntegrity and confidentiality. But I'd guess so.

I displaced the documentation I had up yesterday :D But I should build a kernel and try this out :)

from sbctl.

I believe it does: lkrg-org/lkrg#27

Is there anything that would benefit from an additional testing? Happy to help.

from sbctl.

There is nothing to test yet I believe. I'll try write a separate go library for kernel module signing and see if that works first. Then I'll work on some integration with sbctl.

If you have any ideas, requirements or wants for the command line design please do tell me. I'll poke you once I have some code available :) Thanks!

(Hit the close button by accident :))

from sbctl.

I was wrong :/

Turns out this was possible, but the kernel seperated the UEFI keys into the .platform keyring which the modules does not verify against.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.0.y&id=9dc92c45177ab70e20ae94baa2f2e558da63a9c7

Fedora/RedHat carries patches that adds the platform keyring for kernel module signing, but this as been rejected upstream.

https://lore.kernel.org/lkml/[email protected]/T/

Regardless I have patched the x509 cert code to create certificates the kernel accepts. a6445c4

This was fairly disappointing

from sbctl.

Seems like there is some movement upstream to have MokTrustPlatform tell the kernel if the secure boot keys should be trusted or not. I'm annoyed that a lot of this functionality is gated behind the shim.

https://patchwork.kernel.org/project/keyrings/patch/[email protected]/

from sbctl.

After reading up on the patches I think we can get this to work using sbctl with this workflow.

• Create and set MokListTrustedRT to 1
• Write our keys to MokListRT

And then we can implement kernel module signing with sbctl with kernel 5.18. If the patches do get accepted.

from sbctl.

The patches you mentioned above found the way to the kernel meanwhile. Do you now plan to add the feature to save the keys to MokListRT?

from sbctl.

"Yes", but the issue is that the MOK variables are read from the EFI configuration table setup by shim. So without the shim software in your bootchain the kernel is going to ignore the values regardless.

from sbctl.

You're right - I ignored the MOK / shim issue. This is knocking out systemd-boot which operates w/o shim - what a pity. Maybe it's even better to have different keys for module signing and UEFI secure boot.
Thanks for your work!

from sbctl.

The issue is that there is only two ways to load a trusted key into the Linux keyring. Include one at build-time or use the patch series above. There is no other way currently.

from sbctl.

Well, this is silly. Considering systemd/systemd#20255 has landed now, it could be extended to also enroll a MOK for these kind of cases…

from sbctl.

You would still need to have the shim there, unless you have sd-boot setup the EFI configuration table :)

I wanted to mention it at some point, but it's a bit hard to know when it was relevant information.

from sbctl.

You would still need to have the shim there, unless you have sd-boot setup the EFI configuration table :)

The idea would be that for this pseudo-shim support, you'd rely on the custom keys (and MOK) to be in the secure boot db and additionally add the MOK-related vars. Then you'd not have to implement any of the hackery that shim does, as afaik it does not provide any UEFI runtime APIs to the kernel (and the kernel stub afaik doesn't need any of the shim boot services either).

from sbctl.

Mm, the kernel refuses to read the MOK variables unless they are present in the EFI configuration table. So you would need some shim hackery? Am I misunderstanding something? Simply adding the MOK variables is not enough as stated earlier in this issue.

from sbctl.

Mm, the kernel refuses to read the MOK variables unless they are present in the EFI configuration table.

I see. But installing the MOK key store should be a simple operation that doesn't need hackery (as the UEFI API provides this for us).

from sbctl.

Sure, that would be fine I believe. But be aware that it doesn't really do anything on it's own without the shim.

from sbctl.

But that's the idea, no? Provide a MOK store so that the user can give the kernel a trusted key for kernel module signing, while relying on the regular UEFI secure boot key store (probably without the MOK in it) with custom keys managed by sbctl for boot security.

(If you haven't noticed, I hate shim. It's such an incredibly ugly and hacky solution and should be avoided as much as possible.)

from sbctl.

But that's the idea, no? Provide a MOK store so that the user can give the kernel a trusted key for kernel module signing, while relying on the regular UEFI secure boot key store (probably without the MOK in it) with custom keys managed by sbctl for boot security.

I'm fumbling a bit because it's hard to go from implementation details to see the big-picture :)

(If you haven't noticed, I hate shim. It's such an incredibly ugly and hacky solution and should be avoided as much as possible.)

Which is fine and I somewhat agree, but it's important to realize that the current assumptions from people writing the kernel code, and people working on Secure Boot in Linux distros, regard the shim as the main component in all of this. Moving away from it is hard :/

from sbctl.

Is there an update or workaround for this issue? I'm not able to load v4l2loopback without disabling secure boot on my device.

from sbctl.

You need to use the shim and load the db key into the MOKList.

This isn't something sbctl is going to support without a shim/MOK mode or setup awareness.

from sbctl.

You need to use the shim and load the db key into the MOKList.

Sorry but I don't know what that means. For my setup I generated bundles for each boot entry and put them in /boot/EFI/Linux.

from sbctl.