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@xxxxxxxxxxxxx> 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
