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