Date:   Mon, 10 Jan 2022 20:48:06 -0800
From:   Eric Biggers <ebiggers@kernel.org>
To:     Stefan Berger <stefanb@linux.ibm.com>
Cc:     Mimi Zohar <zohar@linux.ibm.com>, linux-integrity@vger.kernel.org,
        linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/6] ima: support fs-verity file digest based
 signatures
Message-ID: <Yd0MBkL9J5CGF0W9@sol.localdomain>
References: <20220109185517.312280-1-zohar@linux.ibm.com>
 <20220109185517.312280-6-zohar@linux.ibm.com>
 <Ydy3EA9ONY3kn1xr@gmail.com>
 <b4105f9b-98f7-f941-47db-2f72e0c5b8bd@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b4105f9b-98f7-f941-47db-2f72e0c5b8bd@linux.ibm.com>
Precedence: bulk

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