Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 24 Feb 2022 10:46:25 -0800
From:   Eric Biggers <ebiggers@kernel.org>
To:     Mimi Zohar <zohar@linux.ibm.com>
Cc:     linux-integrity@vger.kernel.org,
        Stefan Berger <stefanb@linux.ibm.com>,
        linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 4/8] ima: define a new template field 'd-type' and a
 new template 'ima-ngv2'
Message-ID: <YhfSgeldgCcnzszw@sol.localdomain>
References: <20220211214310.119257-1-zohar@linux.ibm.com>
 <20220211214310.119257-5-zohar@linux.ibm.com>
 <YhbSE/k4mElcehDN@sol.localdomain>
 <b89ec5792da3c284f8e5e058c5568482beccf00d.camel@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b89ec5792da3c284f8e5e058c5568482beccf00d.camel@linux.ibm.com>
Precedence: bulk

On Thu, Feb 24, 2022 at 11:16:51AM -0500, Mimi Zohar wrote:
> On Wed, 2022-02-23 at 16:32 -0800, Eric Biggers wrote:
> > On Fri, Feb 11, 2022 at 04:43:06PM -0500, Mimi Zohar wrote:
> > > In preparation to differentiate between regular IMA file hashes and
> > > fs-verity's file digests, define a new template field named 'd-type'.
> > > Define a new template named 'ima-ngv2', which includes the new 'd-type'
> > > field.
> > > 
> > > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
> > > ---
> > >  security/integrity/ima/ima_template.c     |  3 +++
> > >  security/integrity/ima/ima_template_lib.c | 13 +++++++++++++
> > >  security/integrity/ima/ima_template_lib.h |  2 ++
> > >  3 files changed, 18 insertions(+)
> > > 
> > > diff --git a/security/integrity/ima/ima_template.c b/security/integrity/ima/ima_template.c
> > > index db1ad6d7a57f..b321342e5bee 100644
> > > --- a/security/integrity/ima/ima_template.c
> > > +++ b/security/integrity/ima/ima_template.c
> > > @@ -19,6 +19,7 @@ enum header_fields { HDR_PCR, HDR_DIGEST, HDR_TEMPLATE_NAME,
> > >  static struct ima_template_desc builtin_templates[] = {
> > >  	{.name = IMA_TEMPLATE_IMA_NAME, .fmt = IMA_TEMPLATE_IMA_FMT},
> > >  	{.name = "ima-ng", .fmt = "d-ng|n-ng"},
> > > +	{.name = "ima-ngv2", .fmt = "d-ng|n-ng|d-type"},
> > >  	{.name = "ima-sig", .fmt = "d-ng|n-ng|sig"},
> > >  	{.name = "ima-buf", .fmt = "d-ng|n-ng|buf"},
> > >  	{.name = "ima-modsig", .fmt = "d-ng|n-ng|sig|d-modsig|modsig"},
> > > @@ -40,6 +41,8 @@ static const struct ima_template_field supported_fields[] = {
> > >  	 .field_show = ima_show_template_digest_ng},
> > >  	{.field_id = "n-ng", .field_init = ima_eventname_ng_init,
> > >  	 .field_show = ima_show_template_string},
> > > +	{.field_id = "d-type", .field_init = ima_eventdigest_type_init,
> > > +	 .field_show = ima_show_template_string},
> > >  	{.field_id = "sig", .field_init = ima_eventsig_init,
> > >  	 .field_show = ima_show_template_sig},
> > >  	{.field_id = "buf", .field_init = ima_eventbuf_init,
> > 
> > I notice that the "d-ng" field already contains both the hash algorithm and the
> > hash itself, in the form <algorithm>:<hash>.  Wouldn't it make more sense to
> > define a "d-ngv2" field that contains <type>:<algorithm>:<hash>?  After all,
> > both the type and algorithm are required to interpret the hash.
> > 
> > Or in other words, what about the hash type is different from the hash algorithm
> > that would result in them needing different handling here?
> 
> Thanks, Eric.  I really like your suggestion.  Currently, type is
> defined as either "ima" or "verity".   Are you ok with prefixing each
> record with these strings?
> 

As I mentioned before I think "full_hash" would be more descriptive than "ima".
(All of this is part of IMA.)  It's up to you though.

- Eric