[RFC] IMA Log Snapshotting Design Proposal

[Tushar Sugandhi]

On 8/8/23 14:41, James Bottomley wrote:
> On Tue, 2023-08-08 at 16:09 -0400, Stefan Berger wrote:
>>
>> 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.
> No, the verifier is server side.  It would be the agent or the kernel,
> client side, which gets the quote and shards the log.  That way the
> operation can be done in such a way as to make sure the quote and the
> shard point match.  I'd imagine the verifier can provide some sort of
> guide as to how big it wants the shards to be and the client complies.
Yup. Agreed.
>> 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.
> The idea would be the log shard would be self attesting, that's why
> quote at beginning and end (and probably PCR state at beginning), so no
> verifier required until someone wants to check the log.
>
>> 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.
> That's usually what a runtime verification system is actually
> verifying, yes.
>
>>   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
> A quote is a signature over PCR state signed by an AK, yes.
>
>>   at this point doesn't seem necessary since one presumably can verify
>> the log and PCR states at the end with the 'regular' quote.
> I don't understand this.  A regular quote is a signature over PCR state
> by an AK.  The point about saving the AK in the log for the original is
> that if the *kernel* truncates the log and saves it to a file, it needs
> to generate both the AK and the quote for the top of the file shard.
> That means the AK/EK binding is unverified, but can be verified by
> loading the AK and running the usual tests, which can only be done if
> you have the loadable AK, which is why you need it as part of the log
> saving proposal.
I had this question about the usability of AK/EK in this
context. Although AK/EK + PCR quote is needed to verify the snapshot
shards / IMA logs are not tampered with, I am still not sure why AK/EK
needs to be part of the shard/IMA log. The client sending AK/EK to
attestation service separately would still serve the purpose, right?

For instance, PCR quotes will be signed by AK. So as long as the verifier
trusts the AK/EK, it can verify the quotes are not tampered with.
Replaying IMA log/snapshot can produce the PCR quotes which can be
matched with signed PCR quotes. If they match, then the verifier can
conclude that the IMA log is not tampered with. So AK doesn't need to
be part of the log/snapshot.

BTW, in this proposal, kernel is truncating the log and passing the
truncated buffer to UM.  UM client need to save it to the disk location
of it's choice.


>> 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.
> You have a log shard with PCR state at the beginning and calculated at
> the end, both of which you can verify.  How you establish trust in the
> starting PCR values of the shard is a policy decision, but the policy
> doesn't have to be you see every shard up to boot.  You could take the
> word of the system owner on a handoff of responsibility for instance.
Agreed. You don’t have to go all the way to the boot snapshot
(shard).  It is up to the attestation service which last-known-good PCR
quotes (sometimes referred as golden PCR quotes) it trusts, and verify
the snapshots / logs after that.

~Tushar

> James