Why would you turn off on-demand loading? Where is the difference of loading something ondemand vs explicitly when it comes to security? If you dont trust a module dont ship/install it. If you trust it it shouldnt mayter if you load it at boot or when actually used. What am I missing?
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.
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.
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.
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.