Re: [RFC] IMA Log Snapshotting Design Proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 8/8/23 06:31, 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. 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?

James has addressed this question in his response to this message [1].

Thanks James.

[1] https://lore.kernel.org/all/350ecdcbf7796f488807fcd7983414a02dd71be4.camel@xxxxxxxxxxxxxxxxxxxxx/#r

~Tushar

calculated and checked for matching the quote.  If you lose that, it's
equivalent to the log being tampered with and all bets are off. The
assumption is that because of the impossibility of engineering TPM
extensions, it should be impossible to come up with a fake log that
produces the PCRs of the real one.  If that's violated, then IMA itself
becomes useless.

James


_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec


_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux