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

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

Originally posted by @adrelanos in #148 (comment)

[adrelanos]

https://github.com/Kicksecure/security-misc/blob/master/etc/default/grub.d/40_only_allow_signed_modules.cfg

quote @monsieuremre

On a somewhat unrelated topic, I would prefer the modules signed by Debian organization and not the user.

This isn't possible for out-of-tree modules shipped by Kicksecure. (currently LKRG, tirdad)

Firstly, Debian signs everything they ship anyway. So enrolling the key would be a piece of cake.

Debian's key is there by Debian default. So all modules from Debian work by default.

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.

The signing actually is already automated thanks to DKMS as per Debian default.

The reason why these fail to load with kernel parameter module.sig_enforce=1 enabled is because DKMS's key (which presumably is auto generated on the user's system) isn't enrolled.

[1]:

• On EFI systems: The key could be enrolled using mokutil. (But this might be a confusing interactive process, so maybe still not great.)
• On non-EFI systems: Kicksecure / Whonix VMs as of now are using legacy BIOS boot. (This might change in the future now that grml-debootstrap learned --vmefi.) So mokutil won't work. And there's no other option to enroll the key except kernel recompilation or perhaps recompilation of something else (shim, grub).

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.

Right. Hence created this separate issue.

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.

Same issue as above [1].

[adrelanos]

I cannot find the argument online anymore however module.sig_enforce=1 by itself isn't very useful. Root can install any module, DKMS would compile it, sign it. Compromised root could do the same. As soon as the DKMS key is enrolled into the mok, this might not give much.

So I don't see how it would stop any malware unless it is not sophisticated enough to do the signing. This might be only useful in a context of untrusted root.

[monsieuremre]

Yes. Locally signing the modules or the kernel itself brings nothing. Enabling secure boot is good, if Debian or RedHat or Canonical (or Kicksecure?) or some authority does the signing and not you yourself. Because a compromised OS can just sign stuff with the private key. If and only if there was a system-wide forcefully enforcing Mandatory Access Control Policy (foreshadowing) that is guarding the private keys, that is literally impossible to disable without recompiling or booting a live disk, then maybe in that case this might make sense.

[raja-grewal]

I agree that implementing this is not currently worth the time unless we can have some sort of external signing authority.

I also think it would be quite useful when it comes to developing a untrusted root (secureroot) environment. In this case we could get a user to sign everything on installation but then have a sizable warning indicating that in order to preserve security, they should not boot into root again.