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

Activity

1. adrelanos commented on Nov 5, 2023

   

   adrelanos

   on Nov 5, 2023

   ContributorAuthor

   More actions

   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].
2. adrelanos

   changed the title [-]allow only loading signed kernel modules[/-] [+]allow only loading signed kernel modules / module.sig_enforce=1[/+] on Nov 5, 2023
3. adrelanos commented on Nov 6, 2023

   

   adrelanos

   on Nov 6, 2023

   ContributorAuthor

   More actions

   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.
5. raja-grewal commented on Jan 25, 2024

   

   raja-grewal

   on Jan 25, 2024

   Contributor

   More actions

   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.