[RFC] IMA Log Snapshotting Design Proposal

[Stefan Berger]

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.

I think an ima-buf (or similar) log entry in IMA log would have to appear at the beginning of the
truncated log stating the value of all PCRs that IMA touched (typically only PCR 10
but it can be others). The needs to be done since the quote itself doesn't
provide the state of the individual PCRs. This would at least allow an attestation
client to re-read the log from the beginning (when it is re-start or started for the
first time after the truncation). However, this alone (without the
internal AK quoting the old state) could lead to abuse where I could create totally
fake IMA logs stating the state of the PCRs at the beginning (so the verifier
syncs its internal PCR state to this state). Further, even with the AK-quote that
you propose I may be able to create fake logs and trick a verifier into
trusting the machine IFF it doesn't know what kernel this system was booted with
that I may have hacked to provide a fake AK-quote that just happens to match the
PCR state presented at the beginning of the log.

=> Can a truncated log be made safe for attestation when the attestation starts
only after the truncation occurred?

=> Even if attestation was occurring 'what' state does an attestation server
need to carry around for an attested-to system so that the truncation is 'safe'
and I cannot create fake AK-quotes and fake IMA logs with initial PCR states?
Can I ever restart the client and have it read the truncated log from the
beginning and what type of verification needs to happen on the server then?
It seems like the server would have to remember the state of the IMA PCRs upon
last truncation to detect a possible attack. This would make staring to monitor
a system after truncation impossible -- would be good to know these details.




> should have a beginning and end quote and a record of the AK used.
> Since verifiers like Keylime are already using this beginning and end
> quote for sharded logs, it's the most natural format to feed to
> something externally for verification and it means you don't have to
> invent a new format to do the same thing.
> 
> Regards,
> 
> James
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec