[RFC] IMA Log Snapshotting Design Proposal

[Stefan Berger]

On 8/8/23 14:26, James Bottomley wrote:
> 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


Somehow you have to tell a verifier to take a snapshot of the current state
of the PCRs when it replays the logs to be able to truncate the log. Whether
the state of the PCRs is in the log itself or it's just some sort of entry in
the log indicating a truncation probably doesn't matter for as long as the
verifying side keeps state of the PCRs at point of truncatiokn.

Also, the verifying side needs to take notice of the trustworthiness of the
system at the time the log was truncated in case the attestation client is
restarted and starts out sending the log with the first entry. The PCR state
shown at the beginning of the truncated log (when restarting the attestation
client) must then match when the 'notice' was taken and that determines its
trustworthiness at this point in the log.

That there's a kernel AK signature at this point doesn't seem necessary since one
presumably can verify the log and PCR states at the end with the 'regular' quote.
Nobody should ever trust a system by starting to look at the beginning of a
truncated log. You have to have evaluated all the entries in the log before and
determined whether the system was trustworthy. I don't think the kernel AK
quote buys much - at least not from what I can see.


> 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
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec