On 8/8/23 14: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
Somehow you have to tell a verifier to take a snapshot of the current state
of the PCRs when it replays the logs to be able to truncate the log. Whether
the state of the PCRs is in the log itself or it's just some sort of entry in
the log indicating a truncation probably doesn't matter for as long as the
verifying side keeps state of the PCRs at point of truncatiokn.
Also, the verifying side needs to take notice of the trustworthiness of the
system at the time the log was truncated in case the attestation client is
restarted and starts out sending the log with the first entry. The PCR state
shown at the beginning of the truncated log (when restarting the attestation
client) must then match when the 'notice' was taken and that determines its
trustworthiness at this point in the log.
That there's a kernel AK signature at this point doesn't seem necessary since one
presumably can verify the log and PCR states at the end with the 'regular' quote.
Nobody should ever trust a system by starting to look at the beginning of a
truncated log. You have to have evaluated all the entries in the log before and
determined whether the system was trustworthy. I don't think the kernel AK
quote buys much - at least not from what I can see.
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
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
