Re: [RFC] IMA Log Snapshotting Design Proposal

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2023-08-08 at 09:31 -0400, Stefan Berger wrote:
> 
> 
> On 8/8/23 08:35, James Bottomley wrote:
> > On Mon, 2023-08-07 at 18:49 -0400, Stefan Berger wrote:
> > > 
> > > 
> > > On 8/1/23 17:21, James Bottomley wrote:
> > > > On Tue, 2023-08-01 at 12:12 -0700, Sush Shringarputale wrote:
> > > > [...]
> > > > > Truncating IMA log to reclaim memory is not feasible, since
> > > > > it makes the log go out of sync with the TPM PCR quote making
> > > > > remote attestation fail.
> > > > 
> > > > This assumption isn't entirely true.  It's perfectly possible
> > > > to shard an IMA log using two TPM2_Quote's for the beginning
> > > > and end PCR values to validate the shard.  The IMA log could be
> > > > truncated in the same way (replace the removed part of the log
> > > > with a TPM2_Quote and AK, so the log still validates from the
> > > > beginning quote to the end).
> > > > 
> > > > If you use a TPM2_Quote mechanism to save the log, all you need
> > > > to do is have the kernel generate the quote with an internal
> > > > AK.  You can keep a record of the quote and the AK at the
> > > > beginning of the truncated kernel log.  If the truncated
> > > > entries are saved in a file shard it
> > > 
> > > The truncation seems dangerous to me. Maybe not all the scenarios
> > > with an attestation client (client = reading logs and quoting)
> > > are possible then anymore, such as starting an attestation client
> > > only after truncation but a verifier must have witnessed the
> > > system's PCRs and log state before the truncation occurred.
> > 
> > That's not exactly correct.  Nothing needs to have "witnessed" the
> > starting PCR value because the quote vouches for it (and can vouch
> > for it after the fact).  The only thing you need to verify the
> > quote is the attestation key and the only thing you need to do to
> > trust the attestation key is ensure it was TPM created.  All of
> > that can be verified after the fact as well.  The only thing that
> > can be done to disrupt this is to destroy the TPM (or re-own it).> 
> > Remember the assumption is you *also* have the removed log shard to
> > present.  From that the PCR state of the starting quote can be
> 
> Yes, the whole sequence of old logs needs to be available.

Yes and no.  If the person relying on the logs is happy they've
extracted all the evidentiary value from the log itself then they can
reduce the preceding log shard to simply the PCR values that match the
quote and discard the rest.

>  IF that's the case and the logs can be stitched together seamlessly,
> who then looks at the kernel AK quote and under what circumstances?

For incremental attestation.  Each log shard can be verified using the
base PCR values corresponding to the bottom quote then replayed and the
top quote verified.  This means that logs that aren't needed anymore
can be discarded, which, I recall, was the base reason for this
proposal: reducing IMA memory consumption.  Although all you need to do
is extract the shards from kernel memory to file space and free the
kernel memory.  Since that scheme can keep all logs intact, there's no
reason to further reduce them unless the filesystem is running out of
space.

James