Re: [RFC V2] IMA Log Snapshotting Design Proposal

[Paul Moore <paul@paul-moore.com>]

On Tue, Oct 31, 2023 at 3:15 PM Mimi Zohar <zohar@linux.ibm.com> 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.

> 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.

-- 
paul-moore.com