On 1/10/22 17:45, Eric Biggers wrote:
On Sun, Jan 09, 2022 at 01:55:16PM -0500, Mimi Zohar wrote:+ case IMA_VERITY_DIGSIG: + set_bit(IMA_DIGSIG, &iint->atomic_flags); + + algo = iint->ima_hash->algo; + hash = kzalloc(sizeof(*hash) + hash_digest_size[algo], + GFP_KERNEL); + if (!hash) { + *cause = "verity-hashing-error"; + *status = INTEGRITY_FAIL; + break; + } + + rc = calc_tbs_hash(IMA_VERITY_DIGSIG, iint->ima_hash->algo, + iint->ima_hash->digest, hash); + if (rc) { + *cause = "verity-hashing-error"; + *status = INTEGRITY_FAIL; + break; + } + + rc = integrity_digsig_verify(INTEGRITY_KEYRING_IMA, + (const char *)xattr_value, + xattr_len, hash->digest, + hash->length);This is still verifying a raw hash value, which is wrong as I've explained several times. Yes, you are now hashing the hash algorithm ID together with the original hash value, but at the end the thing being signed/verified is still a raw hash value, which is ambigious. I think I see where the confusion is. If rsa-pkcs1pad is used, then the asymmetric algorithm is parameterized by a hash algorithm, and this hash algorithm's identifier is automatically built-in to the data which is signed/verified. And the data being signed/verified is assumed to be a hash value of the same type. So in this case, the caller doesn't need to handle disambiguating raw hashes. However, asymmetric_verify() also supports ecdsa and ecrdsa signatures. As far as I can tell, those do *not* have the hash algorithm identifier built-in to the data which is signed/verified; they just sign/verify the data given. That
The signatures are generated by evmctl by this code here, which works for RSA and ECDSA and likely also ECRDSA:
https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/master/tree/src/libimaevm.c#l1036 if (!EVP_PKEY_sign_init(ctx)) goto err; st = "EVP_get_digestbyname"; if (!(md = EVP_get_digestbyname(algo))) goto err; st = "EVP_PKEY_CTX_set_signature_md"; if (!EVP_PKEY_CTX_set_signature_md(ctx, md)) goto err; st = "EVP_PKEY_sign"; sigsize = MAX_SIGNATURE_SIZE - sizeof(struct signature_v2_hdr) - 1; if (!EVP_PKEY_sign(ctx, hdr->sig, &sigsize, hash, size)) goto err; len = (int)sigsize;As far as I know, these are not raw signatures but generate the OIDs for RSA + shaXYZ or ECDSA + shaXYZ (1.2.840.10045.4.1 et al) and prepend them to the hash and then sign that.
creates an ambiguity if the hash algorithm identifier is not included. For example, someone might have intended to sign the SHA-256 hash 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b. However, the Streebog or SM3 hash 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b would also pass the signature check too. That's wrong; to have a valid cryptosystem, you mustn't let the adversary choose the crypto algorithms for you.
There's a hash algorithm identifier in the xattr in the header, which is prepended to the bytes of the actual signature. This hash algo identifer tells IMA which hash to use on the file data so that subsequent signature verification with the same hash works. That same hash identifier is then again embedded in the signature using the OID and thus has to match on the signature verification level.
The effectively double hashed data via calc_tbs_hash() above is not good. calc_tbs_hash() is unnecessary.
On the evmctl level the signature should be created from the digest retrieved via ioctl() [or similar I suppose] from fsverity on the file and fsverity presumably then also says what type of hash this is. So, fsverity ioctl response of hash + size of hash and hash_algo become input to the evmctl snippet above. On the kernel level the data from fsverity_get_digest() should be all it takes to verify against an xattr created by evmctl as described.
I'm not sure how this can be reconciled, given the differences between rsa-pkcs1pad and ecdsa and ecrdsa. Could you just use the lowest common denominator and prepend the hash algorithm ID to the hash value, or would that cause issues with rsa-pkcs1pad? In any case, to move forward you're going to need to solve this problem. - Eric
|