Harden the loading of new modules to the kernel after install

[monsieuremre]

Normally it is recommended to have kernel.modules_disabled set to 1. This is the case for all hardened systems, where they pre-define all the modules to be loaded if any. This prevents the loading of new modules to the kernel. Having this set as a sysctl configuration breaks the system, because it also denies systemd-modules-load.service the ability to load the modules that are legitemately needed. I found a workaround. I created a systemd service. It triggers on start up but only after systemd-modules-load.service has already done its thing. Then it disables the loading of new modules to the kernel by setting the aforementioned kernel variable. The system is fully functional.

The only scenario where this would be somewhat inconvenient is maybe if and only if the following exact things happen:

• a user starts up the system
• some peripheral he uses needs drivers that is in the kernel
• the drivers are kind of niche so they don't get loaded by default
• and this device is not plugged in when the system is booting
• so the drivers for that peripheral don't load
• and the user decides to use this peripheral afterwards and plugs it
• and the drivers cannot load, because we disabled it

But if everything is plugged in on system startup, nothing can break even in such an edge scenario, I think.

There are some stuff I am not sure of. First of all, it works as is perfectly. I put the service under lib/systemd/system/harden-module-loading.service and the executable that sets the kernel variable in usr/libexec/security-misc/disable-kernel-module-loading. If another path is more desirable for the executable, we can change that. I also enable the service after install by adding the line systemctl enable disable-module-loading.service into the file debian/security-misc.postinst. I am not sure if this would be right method of enabling the service. If it needs to be taken care of somewhere else, this can also be fixed.

[adrelanos]

Not sure yet. I will add some comments about the implementation now before I comment on the actual functionality.

[adrelanos]

This fortunately isn't needed. #DEBHELPER automagically does that, it honors systemd preset and whatnot.

[monsieuremre]

Good to know.

[adrelanos]

Your new implementation solution is is a clever approach.

Restricting kernel module loading was attempted in the past:

• https://www.kicksecure.com/wiki/Operating_System_Hardening#Module_Loading
• https://forums.whonix.org/t/enforce-kernel-module-software-signature-verification-module-signing-disallow-kernel-module-loading-by-default/7880

It stalled. There was some breakage in the past.

Is this tested? Would these things still be broken with the new implementation?

[monsieuremre]

Yes I have tested most anything. Anything under modules-load.d loads perfectly. No issues there. So this kind of breakage is not present.

When it comes to virtualbox, I think that might still break, but probably not. Because far as I know virtualbox loads its own module to the kernel for virtualization. Thats why it is also not compatible with secure boot without adjusting. But the question is, when does virtual box load its module. If it happens during boot automatically, then no breakage. Just install. It won't work, sure. Then reboot. And it will work. If virtualbox tries to load its modules only when you launch the application, then it won't work.

To be honest, there are better virtualization tools, so breaking virtualbox wouldn't be a big deal for me. To be even more honest, I think there is a good chance it doesn't break anyway because it loads the modules on startup.

Ok quick research results: for example on arch, virtualbox loads its modules on startup automatically. So it wouldn't break. They do it with the file /usr/lib/modules-load.d/virtualbox-host-modules-arch.conf. If an avid virtualbox user wants to continue using it in this hardened system, he can just use the same config file in that path. (Maybe it isn't even needed because they also get loaded automatically on startup on debian too. In that case, no problem.)

[adrelanos]

related:
https://forums.whonix.org/t/enforce-kernel-module-software-signature-verification-module-signing-disallow-kernel-module-loading-by-default/7880/63

Perhaps a separate issue.

(Not suggested as a replacement. Enforcing signature verification would be in addition.)

[monsieuremre]

On a somewhat unrelated topic, I would prefer the modules signed by Debian organization and not the user. Firstly, Debian signs everything they ship anyway. So enrolling the key would be a piece of cake. And also constantly signing stuff on the user end is not the easiest thing to maintain. Because the signing process would have to extremely restricted with a mac policy. Else, once compromised, nothing would stop the intruder from signing their stuff with the private keys that are on the users machine.

I would say this is a little unrelated tho. This pull is about loading modules at all after boot, not that if they are signed or not.

[monsieuremre]

Or if you want to add some third party modules that are not signed by Debian, Kicksecure/Whonix can take it upon itself to sign everything on their end with their keys. Then the user would enroll Whonix's keys.

[monsieuremre]

Yessir, we do it before sysinit.target now. I think that has to be enough.

[adrelanos]

Created

• allow only loading signed kernel modules / module.sig_enforce=1 #156

for it.

[monsieuremre]

Is there any particular issue that is preventing this from being merged, like a lack of testing of a certain application like virtualbox? Or lack of testing in general.

[adrelanos]

I was adjusting the Kicksecure / Whonix VirtualBox installer today to cope up with modules load disabled or module signature verification enforcement.

https://forums.whonix.org/t/whonix-linux-installer-development-discussion/15917/147
https://github.com/Kicksecure/usability-misc/commits/master

[adrelanos]

Also testing this isn't simple. Specifically testing this with Qubes VM kernel is difficult because that itself is difficult to use. Trying to resolve 1 issue and running into another issue.