search

Kicksecure / security-misc

Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - https://www.kicksecure.com/wiki/Security-misc
https://www.kicksecure.com/wiki/Impressum
Other
518 stars 51 forks source link

Harden the loading of new modules to the kernel after install #148

Closed monsieuremre closed 1 year ago

monsieuremre commented 1 year ago

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:

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 commented 1 year ago

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

adrelanos commented 1 year ago

Your new implementation solution is is a clever approach.

Restricting kernel module loading was attempted in the past:

It stalled. There was some breakage in the past.

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

monsieuremre commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

adrelanos commented 1 year ago

Created

for it.

monsieuremre commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.