Message-ID: <a8ea533bf30c658508875948f29341663360db57.camel@HansenPartnership.com>
Date: Mon, 13 May 2024 08:03:53 -0600
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Samuel Ortiz <sameo@...osinc.com>
Cc: Dan Williams <dan.j.williams@...el.com>, Kuppuswamy Sathyanarayanan
 <sathyanarayanan.kuppuswamy@...ux.intel.com>, Qinkun Bao
 <qinkun@...gle.com>,  "Yao, Jiewen" <jiewen.yao@...el.com>, "Xing, Cedric"
 <cedric.xing@...el.com>, Dionna Amalie Glaze <dionnaglaze@...gle.com>,
 biao.lu@...el.com, linux-coco@...ts.linux.dev, 
 linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 4/4] tsm: Allow for extending and reading
 configured RTMRs

On Mon, 2024-05-13 at 12:16 +0200, Samuel Ortiz wrote:
> On Fri, May 10, 2024 at 10:57:37PM -0400, James Bottomley wrote:
> > I'm not really sure where to hang this, since there's no posted
> > agenda
> > or materials for the CCC meeting today.
> 
> The agenda was posted on the linux-coco ml [1]. I sent a link to the
> presentation slides [2] to the thread.

That's great, thanks.

> > However, it struck me you missed a third option: use the ima log
> > format.  This has the advantage that we can define additional
> > events and have them published with a kernel patch (the IMA log
> > format is defined in the kernel).  Thanks to the TCG, it's also CEL
> > compatible but doesn't require any sort of TCG blessing of the
> > events.  Plus we also have existing kernel infrastructure to log to
> > that format.
> 
> That's an interesting idea. It may avoid having to extend the CEL
> spec with a new Content Type, but otoh the current spec defines which
> IMA events are supported. So adding new ones may require to also
> eventually extend the spec. But I guess since IMA is a Linux kernel
> subsystem, changing the kernel code and ABI would de-facto extend the
> TCG CEL IMA spec.

That's what I was assuming since the TCG is currently deferring to IMA
in that regard.

> Here I assume you're talking about the IMA_TEMPLATE CEL specified
> format, which is designed to accomodate for the current kernel IMA
> log format. The main drawback of this format is that the digest does
> not include the whole content event, making the CEL content type, the
> IMA tag name and both lengths (for the content event and the IMA
> content) untrusted for event log verifiers.

That's only because IMA doesn't yet have such an event.  If we're
assuming effectively designing an IMA log format for non repudiation of
external events, one can be added.  Although I wouldn't want to be
hasty: one of the big problems of all options is that no existing log
format really covers the measure container use case and we're not
completely sure what other use cases will arise (the firewall rules
measurements was one that regulated cloud providers seem to think would
be important ... and that has a periodic rush of events, but there will
be others).

However, the current IMA templates (event descriptions) are known by an
ASCII prefix (they all begin ima-):

https://docs.kernel.org/security/IMA-templates.html#supported-template-fields-and-descriptors

So it would be easy to add more with a non ima- prefix.  Note that this
doc is out of date an IMA does support hashes all the way to SHA256
although SHA384 isn't currently listed.

The current record fields are defined in

security/integrity/ima/ima_template.c

> CEL defines another IMA format (IMA_TLV), that hashes the whole event
> content. I think we should at least use that format as our output
> ABI, if we want to use a TCG specified IMA content type.

Possibly.  Although avoiding double hashing may be a useful performance
measure (not really sure how fast records will come in yet).

James

Powered by blists - more mailing lists