enforce kernel module software signature verification [module signing] / disallow kernel module loading by default

The issue was closed.

RFE: add module-load-only-if-modules_disabled.d · Issue #13540 · systemd/systemd · GitHub

I don’t think this is for upstream systemd to manage. It may be possible to declare a static list of modules to load, but it is only possible in very specific circumstances, when you know exactly which hardware, which network devices, which network protocols, which encryption types, etc, etc, any given application will use. But even on a medium-sized distro this would be completely infeasible.

2 Likes

https://lists.archlinux.org/pipermail/arch-general/2015-July/039589.html

Signed modules don’t really offer any added security with a vanilla
kernel because root still has full control over the kernel via other
known mechanisms (i.e. no exploits necessary). The feature is mostly useful for enforcing a policy of not allowing third party modules, similar to the kernel taint bits which can be overwritten if you really feel like doing it.

It’s not a very compelling feature though because it’s only truly useful in combination with a fully read-only root and grsecurity’s romount_protect feature.

A strong MAC policy could also plug the other attack routes… but it’s also going to prevent loading modules for that role anyway.

1 Like

New versions of DKMS have a SIGN_TOOL= feature. Please have a look, see if that looks alright, and give feedback to the DKMS developers:

SIGN_TOOL=

The module signing tool to be run at a build. Two arguments will be passed to the signing tool. The first argument is the target kernel version, the second is the module file path. If the tool exits with a non-zero value, the build will be aborted.

2 Likes
2 Likes

Where is the signing key stored? Where are the signature keys stored?

OR: What is the full command line to sign a kernel module?

Once I know that, should be possible to create an APT DPkg::Post-Invoke setting (similar to this) which signs these kernel modules.

2 Likes

/path/to/kernel_source/certs/signing_key.pem

https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html#manually-signing-modules

So, for us, should be

${kernel_source}/scripts/sign-file sha512 ${kernel_source}/certs/signing_key.pem ${kernel_source}/certs/signing_key.x509 module.ko
2 Likes

Reconsidering.

Better to sign all kernel modules (this would be helpful for purpose of LKRG, tirdad and hardware comparability, namely compatibility with SecureBoot) than no progress in this ticket at all and no signing at all. A drop-in configuration .d folder where kernel modules are white listed opted in could be contributed later.

Please describe the threat model. Folders where kernel modules are stored (and would be auto-signed) are writeable by (super)admin only anyhow. If an adversary gains write access there, it’s game over anyhow. Therefore I don’t see what is gained by white listing which kernel modules should be signed.

1 Like

DKMS getting module signing support.

https://github.com/dell/dkms/blob/master/sign_helper.sh

Dunno when this lands in Debian. Hopefully in Debian bullseye.

If so, since…

…isn’t implemented, package security-misc could config-package-dev displace

/etc/dkms/framework.conf

feature request: Debian package - kernel module signing for kernel_lockdown · Issue #113 · lkrg-org/lkrg · GitHub

Quote:

Some time ago I wrote an article on this subject. it’s in Polish, but all the necessary commands are in place and you will figure out how to make that setup work.

Automatic signing of DKMS kernel modules has been implemented by Debian by default in Debian bookworm.

sudo modinfo /lib/modules/6.1.0-13-amd64/updates/dkms/tirdad.ko | grep sign

signer: DKMS module signing key

Therefore re-enabled only allowing loading signed modules:

Allow only loading signed modules has to be reverted yet again.

Yes, kernel modules are signed by DKMS nowadays with the DKMS key. But that is only “half” of the solution. On

  • A) EFI systems, one would use moktuil to import the key.
  • B) non-EFI systems (such as Whonix for VirtualBox) there is no way to enroll these keys into the kernel.

Hence, the kernel does not know that key and refuses it. In result, kloak fails to load.

There are no other places to enroll the key. Reference:

See:

Table 3.3. Sources for system keyrings

Kernel recompilation would be possible to that’s quite an involved process:

https://wiki.archlinux.org/title/Signed_kernel_modules

Can /var/lib/dkms/mok.pub be enrolled using keyctl?


keyctl:

sudo apt install keyutils

Debian Linux kernel bug report:
key enrollment on non-EFI systems for module.sig_enforce=1 kernel parameter