Maybe these could be considered bugs in these packages? Perhaps packages should declare what modules they need somewhere so such things cannot happen?
To debug…
lsmod on a fully booted, functional system without kernel.modules_disabled=1. Save output.
Then boot with kernel.modules_disabled=1 and run lsmod again. Save output.
Compare the two outputs.
Failing systemd unit files using kernel.modules_disabled=1:
kloakwhonix-firewallvirtualbox-guest-utilslightdm - this may or may not be just a follow up issue of virtualbox-guest-utils failing.This is fixable in principle. Modules can be declared by dropping /usr/lib/modules-load.d snippets. These will be load in time before kernel.modules_disabled=1 kicks in. Tested.
https://www.freedesktop.org/software/systemd/man/modules-load.d.html
Approach to fix: Create a file /usr/lib/modules-load.d/whonix-firewall.conf with contents
nf_tables
more needed etc. etc. Help welcome.
This broke starting a graphical desktop environment in VirtualBox when upgrading Whonix 15.0.0.3.3 from Whonix stable repository.
sudo modprobe vboxdrv
modprobe: ERROR: could not insert ‘vboxdrv’: Required key not available
Upstream bug reports:
Will therefore revert.
Fixing this for real should be possible by either just signing the VirtualBox guest additions modules:
Or better a more generic solution of signing all DKMS modules:
Once this is sorted, can be re-enabled.
I don’t think this should be done. I think we should only allow the modules we need to make the chance something malicious is accidentally signed at a minimum.
Can we just add the scripts to sign the virtualbox modules to a systemd service and make it run at first boot or does it not work that way?
40 kernel modules failed to load when setting kernel.modules_disabled=1 in virtualbox for me. A list of them all is here.
Putting them in /usr/lib/modules-load.d didn’t work. Creating a systemd service that loads every needed module and runs before systemd-sysctl.service worked fine.
Anyhing that break VBox an something as critical as Kloak is a no go.
Yes, I meant we only allow the needed modules like vbox and kloak instead of just allowing all DKMS modules.
Ok. A generic mechanism but no auto signing all.
Might work. Yes, has to be done at first boot. Can’t do at build time likely? Vs signing key.
Also has to be done automatically after DKMS so it does not break during vbox guest additions upgrades.
Would using /etc/kernel/postinst.d work for this or no?
Might work.
Dunno yet if there are DKMS hooks to sign after module build.
Good point. Might need to hook both. Kernel upgrades and vbox guest additions upgrades because each can receive updates independently and then requiring rebuild.
I guess DKMS runs anyhow on kernel upgrade.
Would an apt hook be sufficient?
It turns out, this actually prevents systemd-sysctl.service from starting. I tried adding Before=systemd-sysctl.service to my own systemd service and tried adding After=systemd-sysctl.service to systemd-sysctl but neither worked. Systemd skips it because of some ordering cycle. This prevents any sysctl modifications like the files in /etc/sysctl.d from taking effect.
There are no apt hooks. Dpkg hooks maybe. And dpkg triggers.
Foremost though, for trigger DKMS has to be exhausted.
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.
We might not have to invent a DKMS module signing mechanism.
The VirtualBox upgrade from 6.0.8 to 6.0.10 might have broken this.
As per: https://www.virtualbox.org/ticket/11577?cnum_edit=16#comment:26
Above says that reverting https://www.virtualbox.org/changeset/79186/vbox fixed the issue.
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.
Ah, that’s why it didn’t work for me the last time. I formatted the output of the two lsmods to get the list of modules.
For development / debugging it is useful to use sort to format the output of lsmod to make it easier readable and comparable. I.e.:
sudo lsmod | sort
And write to a file.
sudo lsmod | sort > lsmod_before
Then disable module loading. And load some modules through /usr/lib/modules-load.d folder or so. Then look at lsmod again.
sudo lsmod | sort > lsmod_after
Then compare.
meld lsmod_before lsmod_after
Use of kernel.modules_disabled=1 is now possible and initially documented:
Operating System Hardening - Kicksecure
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:
We’re not the first ever to have this issue. Bug was reported here https://bugzilla.redhat.com/show_bug.cgi?id=1198949 and then dismissed. That doesn’t discourage us discussing this elsewhere.
lsmod columns here:
Module Size Used by
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.