On 2/13/24 03:57, Roberto Sassu wrote:
On Mon, 2024-02-12 at 15:28 -0500, Stefan Berger wrote:
On 2/12/24 12:56, Paul Moore wrote:
On Mon, Feb 12, 2024 at 12:48 PM Stefan Berger stefanb@linux.ibm.com wrote:
On 1/15/24 13:18, Roberto Sassu wrote:
...
+/**
- ima_kernel_module_request - Prevent crypto-pkcs1pad(rsa,*) requests
- @kmod_name: kernel module name
- We have situation, when public_key_verify_signature() in case of RSA > + * algorithm use alg_name to store internal information in order to
- construct an algorithm on the fly, but crypto_larval_lookup() will try
- to use alg_name in order to load kernel module with same name.
- Since we don't have any real "crypto-pkcs1pad(rsa,*)" kernel modules,
- we are safe to fail such module request from crypto_larval_lookup().
- In this way we prevent modprobe execution during digsig verification
- and avoid possible deadlock if modprobe and/or it's dependencies
- also signed with digsig.
This text needs to some reformulation at some point..
There is no time like the present. If you have a suggestion I would love to hear it and I'm sure Roberto would too.
My interpretation of the issue after possibly lossy decoding of the above sentences:
Avoid a deadlock by rejecting a virtual kernel module with the name "crypto-pkcs1pad(rsa,*)". This module may be requested by crypto_larval_lookup() while trying to verify an RSA signature in public_key_verify_signature(). Since the loading of the RSA module may itself cause the request for an RSA signature verification it will otherwise lead to a deadlock.
I can be even more precise I guess (I actually reproduced it). > Avoid a verification loop where verifying the signature of the modprobe binary requires executing modprobe itself. Since the modprobe iint-
mutex is already held when the signature verification is performed, a
deadlock occurs as soon as modprobe is executed within the critical region, since the same lock cannot be taken again.
When ecdsa is used for signing files it could get stuck as well and would need this patch:
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index 45f1a102c599..2e71dc977d43 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -1110,7 +1110,9 @@ EXPORT_SYMBOL_GPL(ima_measure_critical_data); */ static int ima_kernel_module_request(char *kmod_name) { - if (strncmp(kmod_name, "crypto-pkcs1pad(rsa,", 20) == 0) + if (strncmp(kmod_name, "crypto-pkcs1pad(rsa,", 20) == 0 || + strncmp(kmod_name, "crypto-ecdsa-nist-p", 19) == 0 || + strcmp(kmod_name, "cryptomgr") == 0) return -EINVAL;
return 0;
Rejecting cryptomgr seems necessary in the ecdsa case though I am not sure what the side effects of rejecting it all the time could be.
Stefan
This happens when public_key_verify_signature(), in case of RSA algorithm, use alg_name to store internal information in order to construct an algorithm on the fly, but crypto_larval_lookup() will try to use alg_name in order to load a kernel module with same name.
Since we don't have any real "crypto-pkcs1pad(rsa,*)" kernel modules, we are safe to fail such module request from crypto_larval_lookup(), and avoid the verification loop.
Roberto