/usr/src/linux/certs/signing_key.pem

[Alverstone]

Gentoo wiki advises me to remove this file if I use compile-time generated keys for signing modules, despite this file having 600 root:root permissions, and despite me needing it to sign out of tree modules. Ahem? Anyone can unburden my conscience?

[Hu]

When referencing advice from the Wiki, please link to the exact page in question, so that we can see what it says. In this case, searching for signing_key yields no hits, and searching for signing returns numerous clearly extraneous hints (GnuPG, binary packages, etc. - all good information, but not applicable to your question).

With the caveat that I could not find, and therefore could not read, the Wiki's advice, I can speculate. Signing keys should be kept as secret as possible, because if the key becomes known, then the signature requirement offers very little value. Generating the key for use at compile time, using it to sign the modules you build, and then discarding it maximizes the secrecy. Retaining the key risks that it could be used to sign other modules after the build is over. Yes, if you use out of tree modules, then you need to keep the key around until you have signed them. Consider not using out-of-tree modules, which would avoid this conflict.

[Alverstone]

Yeah had to cook my brain a bit to find it again myself.
https://wiki.gentoo.org/wiki/Signed_ker ... signatures

Anyway this reads rather paranoid to me, nobody except root can read the key, and nobody except root can load any modules anyway. I don't see why keeping it around is such a problem, especially in comparison to disabling the modules-sign USE flag.

And no, I won't stop using my out-of-tree modules. Not that I'm using a lot of them, but I won't give them up.

[Hu]

The Wiki directly justifies this. Malware with root privileges could read a root-owned file. A malicious kernel module without a proper signature cannot be loaded, even by root. A malicious kernel module with the proper signature can be loaded by root. Therefore, if you are concerned about malware that obtains root privilege, and want to prevent it from escalating to kernel privilege, you need to deny even root the ability to read this key. Deleting the key is the easiest way to deny root that access.

From the other direction, what threat(s) prompted you to enable module signing? If your threat model supposes that no attacker has root privilege, then what attack could a non-root attacker make on a no-signing kernel that is blocked by your signing-enforced kernel?

[Alverstone]

I enabled it just because I could. I don't know what kind of threat model assumes compromised root user. Certainly not my poor desktop system.

On that note, DKMS doesn't seem to play along so maybe I'll disable it after all.