[RFC V2] IMA Log Snapshotting Design Proposal

[Sush Shringarputale]

On 10/31/2023 11:37 AM, Ken Goldman wrote:
> On 10/19/2023 2:49 PM, Tushar Sugandhi wrote:
>>    f. A new event, "snapshot_aggregate", will be computed and measured
>>         in the IMA log as part of this feature.  It should help the
>>         remote-attestation client/service to benefit from the IMA log
>>         snapshot feature.
>>         The "snapshot_aggregate" event is described in more details in
>>         section "D.1 Snapshot Aggregate Event" below.
>
> What is the use case for the snapshot aggregate?  My thinking is:
>
> 1. The platform must retain the entire measurement list.  Early 
> measurements can never be discarded because a new quote verifier
> must receive the entire log starting at the first measurement.
>
> In this case, isn't the snapshot aggregate redundant?
Not quite. The snapshot aggregate still has a purpose, which is to stitch
together the snapshots on the disk and the in-memory segment of the IMA
log. The specific details are in the RFC Section D.1, quoted here:

The "snapshot_aggregate" marker provides the following benefits:

a. It facilitates the IMA log to be divided into multiple chunks and
provides mechanism to verify the integrity of the system using only the
latest chunks during remote attestation.

b. It provides tangible evidence from Kernel to the attestation client
that IMA log snapshotting has been enabled and at least one snapshot
exists on the system.

c. It helps both the Kernel and UM attestation client define clear
boundaries between multiple snapshots.

d. In the event of multiple snapshots, the last measured
"snapshot_aggregate" marker, which is present in the current segment of
the IMA log, has sufficient information to verify the integrity of the
IMA log segment as well as the previous snapshots using the PCR quotes.

e. In the event of multiple snapshots, say N, if the remote-attestation
service has already processed the last N-1 snapshots, it can efficiently
parse through them by just processing "snapshot_aggregate" events to
compute the PCR quotes needed to verify the events in the last snapshot.
This should drastically improve the IMA log processing efficiency of
the service.

>
> 2. There is a disadvantage to redundant data.  The verifier must 
> support this new event type. It receives this event and must validate 
> the aggregate against the snapshot-ed events. This is an attack 
> surface. The attacker can send an aggregate and snapshot-ed 
> measurements that do not match to exploit a flaw in the verifier.
I disagree with this.  Redundancy is a moot point because
"snapshot_aggregate" is required for the points mentioned above.
- Sush