Looking at the DKMS manpage, the POST and PRE options look interesting.
Also see the dkms.conf overrides sections.
It looks like we can just create a file /etc/dkms/virtualbox-guest.conf that has POST_BUILD=command or PRE_INSTALL=command in it. “command” being the script used to sign the module.
This drop-in folder is functional. Tested. Module got load amd the error message was a different one. Just nontrivial to know the name of the actual name of the module. Not same as lsmod. Try to load it manually beforehand.
I don’t know where to find that file on the disk. So can’t patch this.
Also that ticket seems to be about VirtualBox host modules but I guess the source code for module signing is being re-used for guest additions too. So still related.
Btw this is the tool already on the drive which allows to sign modules.
/usr/src/linux-headers-*/scripts/sign-file
Good to know but hopefully no need to use it for this very purpose.
However, I don’t think the current approach using /usr/lib/modules-load.d folder is a good implementation. Therefore not committed to git yet. Just a proof of concept. It would be better to load those systemd units that require kernel modules early enough before systemd-sysctl.service. Therefore we could avoid being the first distribution writing to /usr/lib/modules-load.d folder.
The problem with /usr/lib/modules-load.d is:
non-standard
not yet discussed with any upstream
manually maintained module lists might get outdated after kernel upgrades, things might break
Modules have “dependency trees”. Therefore I skiped adding those modules to /usr/lib/modules-load.d which are not Used by other modules. The idea was to only add the “top level” modules and let dependencies resolve itself in case in later kernel versions dependencies change (less modules perhaps) no update of the file would be required.
Working on this seems worthwhile. Thereby we can review what kernel modules are load, learn new things, perhaps reduce attack surface. For example:
A graphical session (perhaps X, XFCE and/or lightdm) automatically loads module binfmt_misc. Seems to be this:
Dunno yet if it is a good idea to have this in the kernel. It’s possible to avoid loading this module too but don’t know yet if it breaks anything.
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.