Re: [RFC] IMA Log Snapshotting Design Proposal

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

 





On 8/8/23 11:26, James Bottomley wrote:
On Tue, 2023-08-08 at 09:31 -0400, 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.
Yes and no.  If the person relying on the logs is happy they've
extracted all the evidentiary value from the log itself then they can
reduce the preceding log shard to simply the PCR values that match the
quote and discard the rest.

  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?
For incremental attestation.  Each log shard can be verified using the
base PCR values corresponding to the bottom quote then replayed and the
top quote verified.  This means that logs that aren't needed anymore
can be discarded, which, I recall, was the base reason for this
proposal: reducing IMA memory consumption.  Although all you need to do
is extract the shards from kernel memory to file space and free the
kernel memory.  Since that scheme can keep all logs intact, there's no
reason to further reduce them unless the filesystem is running out of
space.

James
Thank you James for addressing Stefan’s concerns here.
Appreciate it.


~Tushar



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux