Date:   Thu, 2 Dec 2021 13:17:46 -0800
From:   Eric Biggers <ebiggers@kernel.org>
To:     Mimi Zohar <zohar@linux.ibm.com>
Cc:     linux-integrity@vger.kernel.org, linux-fscrypt@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] ima: define a new signature type named
 IMA_VERITY_DIGSIG
Message-ID: <Yak3+n7fcqaM53ct@sol.localdomain>
References: <20211129170057.243127-1-zohar@linux.ibm.com>
 <20211129170057.243127-3-zohar@linux.ibm.com>
 <YaWNX3nwslG/Q2aH@sol.localdomain>
 <6931ed7b1c7d5906bb595447fc24cd8a9b3e3d62.camel@linux.ibm.com>
 <a1b808d664603bfd4bd2f747b59c3e0c51646922.camel@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a1b808d664603bfd4bd2f747b59c3e0c51646922.camel@linux.ibm.com>
Precedence: bulk

On Thu, Dec 02, 2021 at 11:25:05AM -0500, Mimi Zohar wrote:
> Hi Eric,
> 
> On Tue, 2021-11-30 at 13:14 -0500, Mimi Zohar wrote:
> > On Mon, 2021-11-29 at 18:33 -0800, Eric Biggers wrote:
> > > On Mon, Nov 29, 2021 at 12:00:55PM -0500, Mimi Zohar wrote:
> > > > To differentiate between a regular file hash and an fs-verity file digest
> > > > based signature stored as security.ima xattr, define a new signature type
> > > > named IMA_VERITY_DIGSIG.
> > > > 
> > > > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
> > > 
> > > For this new signature type, what bytes are actually signed?  It looks like it's
> > > just the raw digest, which isn't sufficient since it is ambiguous.  It needs to
> > > include information that makes it clear what the signer is actually signing,
> > > such as "this is an fs-verity SHA-256 file digest".  See
> > > 'struct fsverity_formatted_digest' for an example of this (but it isn't
> > > necessary to use that exact structure).
> > > 
> > > I think the existing IMA signatures have the same problem (but it is hard for me
> > > to understand the code).  However, a new signature type doesn't have
> > > backwards-compatibility concerns, so it could be done right.
> > 
> > As this change should probably be applicable to all signature types,
> > the signature version in the  signature_v2_hdr should be bumped.  The
> > existing signature version could co-exist with the new signature
> > version.
> 
> By signing the file hash, the sig field in the IMA measurement list can
> be directly verified against the digest field.  For appended
> signatures, we defined a new template named ima-modsig which contains
> two file hashes, with and without the appended signature.
> 
> Similarly, by signing a digest containing other metadata and fs-
> verity's file digest, the measurement list should include both digests.
> Otherwise the consumer of the measurement list would first need to
> calculate the signed digest before verifying the signature.
> 
> Options:
> - Include just fs-verity's file digest and the signature in the
> measurement list.  Leave it to the consumer of the measurement list to
> deal with.
> - Define a new template format to include both digests, add a new field
> in the iint for the signed digest.  (Much more work.)
> - As originally posted, directly sign fs-verity's file digest.

I don't really have enough knowledge about IMA and how it is used to decide on
one approach or the other.  Note that earlier I mentioned that it would be
possible to have an fs-verity setting that makes a full file digest be included
in the fsverity_descriptor, so it gets covered by the fs-verity file digest and
is also retrievable in constant time like the fs-verity file digest is.

If you'd like to solve this problem at the IMA layer instead, by storing the
full file digest in an xattr and signing both the full file digest and fs-verity
file digest together, that would achieve the same goal of making the full file
digest available, and wouldn't require any changes to fs-verity.  This would
assume that the file would be signed, though.  What about audit-only mode
without signatures; is that something you care about?

Alternatively, maybe this problem doesn't need to be solved at all and IMA would
be fine with the fs-verity file digest only, and not need the full file hash
too.  I don't know the answer to that; I think it's up to you to decide.

- Eric