That’s a good idea. Set a timeout of 30 seconds or something so newly plugged in hardware has a chance to load its modules before system use.
Time based will be prone for race conditions. Something (not) working on fast vs slower computers / under light/heavy (host) load. systemd allows to define exactly when is a good time to dispatch this the question is just what is the right time to do this.
Documentation for /proc/sys/kernel/ — The Linux Kernel documentation says the same
modules_disabled:
A toggle value indicating if modules are allowed to be loaded in an otherwise modular kernel. This toggle defaults to off (0), but can be set true (1). Once true, modules can be neither loaded nor unloaded, and the toggle cannot be set back to false. Generally used with the “kexec_load_disabled” toggle.
Btw we have kexec disabled already as per:
https://github.com/Whonix/security-misc/blob/master/etc/sysctl.d/kexec.conf
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
:
kloak
whonix-firewall
virtualbox-guest-utils
-
lightdm
- this may or may not be just a follow up issue ofvirtualbox-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:
- GitHub - ivan-californias/vbox-sign-modules: Scripts for signing virtualbox kernel modules
- maj-scripts/vboxsign at master · majal/maj-scripts · GitHub
- Signing VirtualBox Kernel Modules · GitHub
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.