An alternative way would be to create a systemd service that runs after systemd-modules-load.service and sets kernel.modules_disabled=1.
This should make sure that all modules are loaded before we set that setting. I haven’t tested this though and it might lead to another error like with systemd-sysctl.
I don’t think that’s a good idea, systemd-sysctl is one of the first services to start. Starting a bunch of units before that would likely be way too early.
An alternative way would be to create a systemd service that runs after systemd-modules-load.service and sets kernel.modules_disabled=1.
… and after systemd-sysctl.service (since that can be used to
influence kernel module loading).
This should make sure that all modules are loaded before we set that setting.> I haven’t tested this though and it might lead to another error like
with systemd-sysctl.
Does not work for sure. kloak as is now would still fail to load since
trying to autoload the uinput kernel module. We’d still need to use /usr/lib/modules-load.d.
Need to find out if there is a better way than requiring all upstreams
to define their modules in /usr/lib/modules-load.d.
I don’t think that’s a good idea, systemd-sysctl is one of the first services to start. Starting a bunch of units before that would likely be way too early.
Good point. Might be inappropriate for some services indeed. Need to ask
various upstream, not sure to whom this is up. Looks like unchartered
territory. Very few search results on search engines.
It turns out, this won’t only be useful for the root user. Unprivileged users can still indirectly load kernel modules through auto-loading.
E.g. an attacker tries to use X protocol, the needed kernel module is auto-loaded even though the attacker is unprivileged and then the attacker exploits a vulnerability in X module.
Setting kernel.modules_disabled=1 will prevent the module from being loaded regardless.
Blacklisting the modules in modprobe.d would also prevent auto-loading of that specific module as it makes run /bin/false instead of auto-loading it.
There is a currently unaccepted patch that restricts auto-loading of kernel modules to root only called the Timgad LSM though.
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.
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.