On 11/16/23 14:28, Paul Moore wrote:
On Tue, Oct 31, 2023 at 3:15 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
On Thu, 2023-10-19 at 11:49 -0700, Tushar Sugandhi wrote:
[...]
-----------------------------------------------------------------------
| C.1 Solution Summary |
-----------------------------------------------------------------------
To achieve the goals described in the section above, we propose the
following changes to the IMA subsystem.
a. The IMA log from Kernel memory will be offloaded to some
persistent storage disk to keep the system running reliably
without facing memory pressure.
More details, alternate approaches considered etc. are present
in section "D.3 Choices for Storing Snapshots" below.
b. The IMA log will be divided into multiple chunks (snapshots).
Each snapshot would be a delta between the two instances when
the log was offloaded from memory to the persistent storage
disk.
c. Some UM process (like a remote-attestation-client) will be
responsible for writing the IMA log snapshot to the disk.
d. The same UM process would be responsible for triggering the IMA
log snapshot.
e. There will be a well-known location for storing the IMA log
snapshots on the disk. It will be non-trivial for UM processes
to change that location after booting into the Kernel.
f. A new event, "snapshot_aggregate", will be computed and measured
in the IMA log as part of this feature. It should help the
remote-attestation client/service to benefit from the IMA log
snapshot feature.
The "snapshot_aggregate" event is described in more details in
section "D.1 Snapshot Aggregate Event" below.
g. If the existing remote-attestation client/services do not change
to benefit from this feature or do not trigger the snapshot,
the Kernel will continue to have it's current functionality of
maintaining an in-memory full IMA log.
Additionally, the remote-attestation client/services need to be updated
to benefit from the IMA log snapshot feature. These proposed changes
are described in section "D.4 Remote-Attestation Client/Service Side
Changes" below, but their implementation is out of scope for this
proposal.
As previously said on v1,
This design seems overly complex and requires synchronization between the
"snapshot" record and exporting the records from the measurement list. [...]
Concerns:
- Pausing extending the measurement list.
Nothing has changed in terms of the complexity or in terms of pausing
the measurement list. Pausing the measurement list is a non starter.
The measurement list would only need to be paused for the amount of
time it would require to generate the snapshot_aggregate entry, which
should be minimal and only occurs when a privileged userspace requests
a snapshot operation. The snapshot remains opt-in functionality, and
even then there is the possibility that the kernel could reject the
snapshot request if generating the snapshot_aggregate entry was deemed
too costly (as determined by the kernel) at that point in time.
Thanks Paul for responding and sharing your thoughts.
Hi Mimi,
To address your concern about pausing the measurements -
We are not proposing to pause the measurements for the entire duration
of UM <--> Kernel interaction while taking a snapshot.
We are simply proposing to pause the measurements when we get the TPM
PCR quotes to add them to "snapshot_aggregate". (which should be a very
small time window). IMA already has this mechanism when two separate
modules try to add entry to IMA log - by using
mutex_lock(&ima_extend_list_mutex); in ima_add_template_entry.
We plan to use this existing locking functionality.
Hope this addresses your concern about pausing extending the measurement
list.
~Tushar
Userspace can already export the IMA measurement list(s) via the
securityfs {ascii,binary}_runtime_measurements file(s) and do whatever
it wants with it. All that is missing in the kernel is the ability to
trim the measurement list, which doesn't seem all that complicated.
From my perspective what has been presented is basically just trimming
the in-memory measurement log, the additional complexity (which really
doesn't look that bad IMO) is there to ensure robustness in the face
of an unreliable userspace (processes die, get killed, etc.) and to
establish a new, transitive root of trust in the newly trimmed
in-memory log.
I suppose one could simplify things greatly by having a design where
userspace captures the measurement log and then writes the number of
measurement records to trim from the start of the measurement log to a
sysfs file and the kernel acts on that. You could do this with, or
without, the snapshot_aggregate entry concept; in fact that could be
something that was controlled by userspace, e.g. write the number of
lines and a flag to indicate if a snapshot_aggregate was desired to
the sysfs file. I can't say I've thought it all the way through to
make sure there are no gotchas, but I'm guessing that is about as
simple as one can get.
If there is something else you had in mind, Mimi, please share the
details. This is a very real problem we are facing and we want to
work to get a solution upstream.
