On 8/11/23 11:57, Tushar Sugandhi wrote:
[1] https://patchwork.kernel.org/project/linux-integrity/cover/20230801181917.8535-1-tusharsu@xxxxxxxxxxxxxxxxxxx/
The shards should will need to be written into some sort of standard location or a config file needs to
be defined, so that everyone knows where to find them and how they are named.
We thought about well known standard location earlier.
Letting the Kernel choose the name/location of the snapshot
file comes with its own complexity. Our initial stance is we don’t
want to handle that at Kernel level, and let the UM client choose
the location/naming of the snapshot files. But we are happy to
reconsider if the community requests it.
I would also let user space do the snapshotting but all applications
relying on shards should know where they are located on the system
and what the naming scheme is so they can be process in proper order.
evmctl for example would have to know where the shards are if keylime
agent had taken snapshots.
Yes. If the “PCR quotes in the snapshot_aggregate event in IMA log”
PCR quote or 'quotes'? Why multiple?
Form your proposal but you may have changed your opinion following what I see in other messages:
"- 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"."
Afaik TPM quote's don't give you the state of the individual PCR values, therefore
I would expect to at least find the 'PCR values' of all the PCRs that IMA touched to
be in the snapshot_aggregate so I can replay all the following events on top of these
PCR values and come up with the values that were used in the "final PCR quote". This
is unless you expect the server to take an automatic snapshot of the values of the
PCRs that it computed while evaluating the log in case it ever needs to go back.
I meant a single set of PCR values captured when snapshot_aggregate
is logged. Sorry for the confusion.
Ok.
+ "replay of rest of the events in IMA log" results in the “final PCR quotes”
that matches with the “AK signed PCR quotes” sent by the client, then the truncated
IMA log can be trusted. The verifier can either ‘trust’ the “PCR quotes in the
snapshot_aggregate event in IMA log” or it can ask for the (n-1)th snapshot shard
to check the past events.
For anything regarding determining the 'trustworthiness of a system' one would have to
be able to go back to the very beginning of the log *or* remember in what state a
system was when the latest snapshot was taken so that if a restart happens it can resume
with that assumption about state of trustworthiness and know what the values of the PCRs
were at that time so it can resume replaying the log (or the server would get these
values from the log).
Correct. We intend to support the above. I hope our proposal
description captures it. BTW, when you say ‘restart’, you mean the UM
process restart, right? Because in case of a Kernel restart
Yes, client restart not reboot.
(i.e. cold-boot) the past IMA log (and the TPM state) is lost,
and old snapshots (if any) are useless.
Right. Some script should run on boot and delete all contents of the directory where the log
shards are.
The AK quotes by the kernel (which adds a 2nd AK key) that James is proposing
could be useful if the entire log, consisting of multiple shards, is very large and
cannot be transferred from the client to the server in one go so that the server could
evaluate the 'final PCR quote' immediately . However, if a client can indicated 'I will
send more the next time and I have this much more to transfer' and the server allows
this multiple times (until all the 1MB shards of the 20MB log are transferred) then that
kernel AK key would not be necessary since presumably the "final PCR quote", created
by a user space client, would resolve whether the entire log is trustworthy.
See my responses to James today [2]
[2] https://lore.kernel.org/all/72e39852-1ff1-c7f6-ac7e-593e8142dbe8@xxxxxxxxxxxxxxxxxxx/
I think James was proposing one AK, possibly persisted in the TPM's NVRAM. Still, the less keys
that are involved in this the better...
Stefan
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
