Re: [PATCH 1/1] IMA event log trimming

[Gregory Lumen <gregorylumen@linux.microsoft.com>]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

> Rather than designing the interface absent use cases, could we give use
> cases first so we know it fits?

I would also like to request that we include operational considerations in 
the interface design; specifically, which additional signals can or should 
be made available to UM to assist in diagnosing log validation failures. 
This seems called for as any form of log trimming will introduce a new 
potential cause for validation failures (unexpected trimming).

With the proposed changes, the only signal available to system operators 
is the validation failure itself, with no signal that could be used to 
determine if the failure was the result of an unexpected trim or a loss of 
synchronization between the log and the PCRs (either through an unexpected 
PCR extend, or tampering with the measurement list). Any of these may 
indicate malicious activity, but they may also result from system 
configuration issues that operators would need to diagnose and resolve.

Tracking and exposing either the total number of trimmed measurements or 
the most recent trimmed-to PCR values by the kernel would allow system 
operators to determine whether a failure was caused by unexpected trimming 
or integrity issues. (Storing the PCR values also enables validation of 
the retained measurements even after an unexpected trim, though I’m unsure 
how often that signal would prove useful.)

Neither approach appears to add any additional attack surface beyond 
raising the likelihood of incorrectly or insecurely implemented UM 
attestation agents. Though that risk (and the additional kernel 
complexity) should be weighed against the value of the additional 
diagnostic signals.

-Gregory Lumen