[RFC] IMA Log Snapshotting Design Proposal - aggregate

[Ken Goldman]

On 9/1/2023 6:06 PM, Tushar Sugandhi wrote:
> 
> 
> On 8/30/23 11:12, Ken Goldman wrote:
>> On 8/1/2023 3:12 PM, Sush Shringarputale wrote:
>>> - A user-mode process will trigger the snapshot by opening a file in 
>>> SysFS
>>>    say /sys/kernel/security/ima/snapshot (referred to as 
>>> sysk_ima_snapshot_file
>>>    here onwards).
>>> - 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".
>>
>> If this is relying on a user-mode process, is there a concern that the 
>> process doesn't run. Might it be safer to have the kernel trigger the
>> snapshot.
>>
> The UM process here would be typically an attestation client
> which passes on the IMA log to the remote service for attestation.
> If the process doesn't run, the client will operate the same way as it
> does currently.

I see.

1. Ensure that the attestation client stores the snapshot in a 
well-known and widely readable location.  There can be more than one 
attestation client, and all need access to the snapshot.

There is a privacy concern around making the snapshot world-read.

2. Is there a concern that, if the client doesn't run, it doesn't solve 
the kernel memory issue?  Is this relying on a UM process to solve a 
kernel issue?
> 
>> PCR reads are not atomic, with each other and with event log appends. 
>> Is this an issue?
>>
> In this design, reading the PCR plus adding the snapshot_aggregate
> has to be an atomic operation.  Other IMA events shouldn't interfere
> with this operation. Just like IMA ensures adding an entry to the log
> plus PCR extension happens in an atomic way by holding the
> ima_extend_list_mutex [2], we intend to use a similar mechanism to
> ensure reading the PCR plus adding the snapshot_aggregate remains an
> atomic operation.  And since taking a snapshot would be a rare event
> compared to adding a generic event to IMA log - overall we expect a low
> overhead in case of snapshotting.

How would that work?  The PCR read is UM, but IMA events are kernel. The 
UM operation cannot block the kernel or there can be a deadlock, right?

(UM) PCR reads can take multiple TPM commands, and they should not block 
an (kernel) extend.

>> What is the purpose of the snapshot aggregate?  Since the entire event 
>> log has to be retained and sent to the verifier, is the aggregate 
>> redundant?
> 
> The goals of snapshot_aggregate marker are:
>      1. To allow the IMA log to be divided into multiple chunks and
>         provide attestation service the ability to verify and use the
>         latest chunk (i.e. snapshot ) for attestation.

I believe that the verifier needs the entire log the first time, whether 
there is a snapshot or not.  Shouldn't the snapshot process be opaque to 
the verifier?

> 
>      2. To indicate to the attestation service that the client device has
>         IMA log snapshotting feature enabled, and at least one snapshot
>         is taken.  So that the service can ask for previous snapshots
>         as needed.

Why does the verifier need this?  The first time, it asks for events 
starting at #0.  Next time, it asks for what's new.  It's independent of 
__where__ the log comes from.

> 
>      3. In the event of multiple snapshots, the snapshot_aggregate
>         marker has sufficient information to verify the integrity
>         of latest subset of isolated snapshots (with the help of PCR
>         quote of course)

A new verifier needs the entire log, no matter how many snapshots have 
been taken.

> 
>      4. snapshot_aggregate helps both kernel and UM define clear
>         boundaries between multiple snapshots.
>         (each new snapshot starts with either the first boot_aggregate
>          or a snapshot_aggregate event)
> 
> The overall goals of IMA log snapshotting feature are:
>      a. to relieve memory pressure on the client device.
> 
>      b. to make attestation service side processing more efficient
>         They don't have to deal with the entire log since boot,
>         as you mentioned on

I don't think snapshotting affects the verifier at all. The attestor is 
a bit more complicated, but not significantly.