enforce kernel module software signature verification [module signing] / disallow kernel module loading by default

Development
,
#18

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.

2 Likes
#19

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.

1 Like
#20

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

2 Likes
#21

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.

2 Likes
#22

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 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.

2 Likes
#23

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.

2 Likes
kernel recompilation for better hardening
Whonix VirtualBox VMs no longer boot after updating
#24
2 Likes
#25

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?

1 Like
#26

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.

1 Like
#27

Anyhing that break VBox an something as critical as Kloak is a no go.

#28

Yes, I meant we only allow the needed modules like vbox and kloak instead of just allowing all DKMS modules.

2 Likes
#29

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.

2 Likes
#30

Would using /etc/kernel/postinst.d work for this or no?

1 Like
#31

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.

1 Like
#32

Would an apt hook be sufficient?

#33

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.

1 Like
#34

There are no apt hooks. Dpkg hooks maybe. And dpkg triggers.

Foremost though, for trigger DKMS has to be exhausted.

2 Likes
#35

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.

1 Like
#36

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.

1 Like
#37

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.

1 Like