[RFC] IMA Log Snapshotting Design Proposal

[Stefan Berger]

On 8/11/23 11:57, Tushar Sugandhi wrote:
> 
> 
> 
> [1] https://patchwork.kernel.org/project/linux-integrity/cover/20230801181917.8535-1-tusharsu@linux.microsoft.com/
> 
>> The shards should will need to be written into some sort of standard location or a config file needs to
>> be defined, so that everyone knows where to find them and how they are named.
>>
> We thought about well known standard location earlier.
> Letting the Kernel choose the name/location of the snapshot
> file comes with its own complexity. Our initial stance is we don’t
> want to handle that at Kernel level, and let the UM client choose
> the location/naming of the snapshot files. But we are happy to
> reconsider if the community requests it.

I would also let user space do the snapshotting but all applications
relying on shards should know where they are located on the system
and what the naming scheme is so they can be  process in proper order.
evmctl for example would have to know where the shards are if keylime
agent had taken snapshots.



>>> Yes. If the “PCR quotes in the snapshot_aggregate event in IMA log”
>>
>> PCR quote or 'quotes'? Why multiple?
>>
>> Form your proposal but you may have changed your opinion  following what I see in other messages:
>> "- The Kernel will get the current TPM PCR values and PCR update counter [2]
>>     and store them as template data in a new IMA event "snapshot_aggregate"."
>>
>> Afaik TPM quote's don't give you the state of the individual PCR values, therefore
>> I would expect to at least find the 'PCR values' of all the PCRs that IMA touched to
>> be in the snapshot_aggregate so I can replay all the following events on top of these
>> PCR values and come up with the values that were used in the "final PCR quote". This
>> is unless you expect the server to take an automatic snapshot of the values of the
>> PCRs  that it computed while evaluating the log in case it ever needs to go back.
>>
> I meant a single set of PCR values captured when snapshot_aggregate
> is logged. Sorry for the confusion.

Ok.

> 
>>> + "replay of rest of the events in IMA log" results in the “final PCR quotes”
>>> that matches with the “AK signed PCR quotes” sent by the client, then the truncated
>>> IMA log can be trusted. The verifier can either ‘trust’ the “PCR quotes in the
>>> snapshot_aggregate event in IMA log” or it can ask for the (n-1)th snapshot shard
>>> to check the past events.
>>
>> For anything regarding determining the 'trustworthiness of a system' one would have to
>> be able to go back to the very beginning of the log *or* remember in what state a
>> system was when the latest snapshot was taken so that if a restart happens it can resume
>> with that assumption about state of trustworthiness and know what the values of the PCRs
>> were at that time so it can resume replaying the log (or the server would get these
>> values from the log).
>>
> Correct. We intend to support the above. I hope our proposal
> description captures it. BTW, when you say ‘restart’, you mean the UM
> process restart, right? Because in case of a Kernel restart

Yes, client restart not reboot.

> (i.e. cold-boot) the past IMA log (and the TPM state) is lost,
> and old snapshots (if any) are useless.

Right. Some script should run on boot and delete all contents of the directory where the log
shards are.

> 
>> The AK quotes by the kernel (which adds a 2nd AK key) that James is proposing
>> could be useful if the entire log, consisting of multiple shards, is very large and
>> cannot be transferred from the client to the server in one go so that the server could
>> evaluate the 'final PCR quote' immediately . However, if a client can indicated 'I will
>> send more the next time and I have this much more to transfer' and the server allows
>> this multiple times (until all the 1MB shards of the 20MB log are transferred) then that
>> kernel AK key would not be necessary since presumably the "final PCR quote", created
>> by a user space client, would resolve whether the entire log is trustworthy.
>>
> See my responses to James today [2]
> 
> [2] https://lore.kernel.org/all/72e39852-1ff1-c7f6-ac7e-593e8142dbe8@linux.microsoft.com/

I think James was proposing one AK, possibly persisted in the TPM's NVRAM. Still, the less keys
that are involved in this the better...

    Stefan