linux-kernel - Re: [PATCH v2 5/6] ima: support fs-verity file digest based signatures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Yd0MBkL9J5CGF0W9@sol.localdomain>
Date:   Mon, 10 Jan 2022 20:48:06 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     Stefan Berger <stefanb@...ux.ibm.com>
Cc:     Mimi Zohar <zohar@...ux.ibm.com>, linux-integrity@...r.kernel.org,
        linux-fscrypt@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/6] ima: support fs-verity file digest based
 signatures

On Mon, Jan 10, 2022 at 10:26:23PM -0500, Stefan Berger wrote:
> 
> 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.

As I said, this appears to be true for RSA but not for ECDSA or ECRDSA.

- Eric