Re: [RFC] Persist ima logs to disk

[Mimi Zohar <zohar@linux.ibm.com>]

On Thu, 2021-01-07 at 13:48 -0800, James Bottomley wrote:
> On Thu, 2021-01-07 at 15:51 -0500, Mimi Zohar wrote:
> > On Thu, 2021-01-07 at 12:37 -0800, James Bottomley wrote:
> > > On Thu, 2021-01-07 at 15:02 -0500, Mimi Zohar wrote:
> > > > On Thu, 2021-01-07 at 08:42 -0800, James Bottomley wrote:
> [...]
> > > > > What about having a log entry that's the current PCR
> > > > > value?  Then stretches of the log starting with these entries
> > > > > would be independently verifiable provided you had a way of
> > > > > trusting the PCR value.  It might be possible to get the TPM to
> > > > > add a signed quote as an optional part of the log entry (of
> > > > > course this brings other problems like which key do you use for
> > > > > the signing and how does it get verified) which would provide
> > > > > the trust and would definitively allow you to archive log
> > > > > segments and still make the rest of the log useful.
> > > > 
> > > > The current PCR values are aggregated and stored in the
> > > > boot_aggregate record.  As part of the new boot_aggregate record
> > > > format, the individual PCR values could be included.
> > > 
> > > I don't think we care about the boot aggregate ... it's just the
> > > initial log entry that ties the boot state to the initial runtime
> > > state.  All we need for the proposed entry is the current value of
> > > the IMA PCR so provided you trust that value it becomes a base on
> > > which the following measurements can build and be trusted.
> > 
> > The IMA measurement list may contain multiple PCRs, not just the
> > default IMA PCR.   Each kexec results in an additional boot_aggregate
> > record, but an equivalent record for after truncating the measurement
> > list might help.
> 
> Right, this would specifically be only of the IMA PCR so you can use it
> as a base to begin the hash of the following log segment.  The log can
> still contain other boot aggregate entries, but the assumption is that
> boot aggregate entries in the prior log have already been evaluated.

IMA may be configured on a per rule basis to measure files into
different PCRs.  Between the previous boot aggregate record and
truncating the measurement list, other PCRs may have been extended.

> 
> > > > But this doesn't address where the offloaded measurement list
> > > > will be stored, how long the list will be retained, nor who
> > > > guarantees the integrity of the offloaded list.  In addition,
> > > > different form factors will have different requirements.
> > > 
> > > I'm not sure you need any store at all.  The basic idea is that the
> > > log is divided into individually verifiable segments.  For auditing
> > > purposes you could keep all segments, so you have the entire log,
> > > but if you've acted on the prior log entries and you don't have an
> > > audit reason to keep them, you could erase that segment of the log
> > > because you've placed all your trust in the prior log segments into
> > > the PCR entry that forms the base of your current segment.
> > > 
> > > Essentially the question devolves to what mechanisms can give you
> > > this trust in the base PCR log entry.
> > 
> > 
> > Not retaining the entire measurement list would limit it's verification
> > to a single server/system.
> 
> Well, it would limit its verification to just that log segment, yes.

Verifying only the current log segment only makes sense, if the
previous log segments were previously verified.

> 
> I'm thinking in the cloud there are a couple of potential consumers:  
> 
>    1. The cloud monitor, which acts on the verified log, such as killing a
>       node for trying to execute an unverified binary or emailing the
>       guest owner.  This type of consumer doesn't need the historical log,
>       they just need to verify the entries they haven't already seen and
>       act on them according to whatever policy they're given.
>    2. The second type of cloud consumer is the audit case where the
>       aggregate hash is used to assure some auditor, some time after the
>       actual events, that the entire runtime of the VM was properly
>       monitored and the auditor wants to see the log  or a segment of it
>       to prove the hash.
> 
> Case 1 doesn't need historical storage, case 2 definitely does.  I
> think we should support both use cases particularly in the long running
> scenario where we need to recover memory.  Having verifiable log
> segments seems to satisfy both cases, but what you do with the segments
> would vary.

As Ken previously pointed out, the attestation server itself can
request only the new measurements.

Mimi