linux-kernel - Re: [PATCH 2/4] ima: define a new signature type named IMA_VERITY

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 02 Dec 2021 16:56:10 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     linux-integrity@...r.kernel.org, linux-fscrypt@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] ima: define a new signature type named
 IMA_VERITY_DIGSIG

On Thu, 2021-12-02 at 13:17 -0800, Eric Biggers wrote:
> 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@...ux.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.

I just posted v1 which implements option 1, including the fsverity file
digest in
the measurement list.  Both option 2 or including the actual file hash,
will require a new template format with two digests.

Mimi