Re: [RFC PATCH v2 4/4] tsm: Allow for extending and reading configured RTMRs

From: Xing, Cedric
Date: Thu May 16 2024 - 04:34:02 EST

On 5/13/2024 10:08 PM, Samuel Ortiz wrote:
On Mon, May 13, 2024 at 08:03:53AM -0600, James Bottomley wrote:
On Mon, 2024-05-13 at 12:16 +0200, Samuel Ortiz wrote:
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.

If we were to follow the IMA_TEMPLATE format as our output RTMR ABI for
the event log, adding one or more IMA events would not change the fact
that the event and content type would not be hashed into the extended
digest. Unless we want to specify a different behaviour for each IMA
event, and then verifiers would have interpret the digest construction
differently depending on the IMA_TEMPLATE nested event type. And that's
not pretty IMHO.

Agreed. This misses the design objective of separating storage from semantics of event records.

Using the IMA_TLV content type would make that cut cleaner at least. A
digest is built on the whole content event, for all event types. And the
content and event types are trusted, i.e. the verifier can securely map
events to the reported event types.

The numerical T would need to be allocated/tracked by a central registry. This won't work for applications designed/developed outside of the kernel community, as they won't have a reliable way to avoid conflicts with each other. Thus, T needs to be a string, but that violates IMA_TLV definition. This is kinda fitting a square peg into a round hole IMHO.

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).

Right. A new CEL content type would give us more freedom in that regard,
as it would allow us to define our own event content value in a more
flexible way. Instead of the nested TLV approach that IMA_TLV follows,
having one where the T would be a max length string defining the creator
of the event (a.k.a. the attester), would avoid having to formally
define each and every new event. That's where option #2 in the
presentation was heading to.

Agreed. In fact, the 2 primary design objectives of this event log are (1) to separate storage from semantics of event records and (2) to allow applications to define custom events and avoid conflicts with each other reliably. IMA_TLV meets the 1st objective but misses the 2nd; while IMA_TEMPLATE meets the 2nd but misses the 1st. And that's how we came to this Option #2.

-Cedric