On Tue, 2023-11-21 at 23:27 -0500, Paul Moore wrote:
> On Thu, Nov 16, 2023 at 5:28 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > On Tue, Oct 31, 2023 at 3:15 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
>
> ...
>
> > > 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.
>
> Any thoughts on this Mimi? We have a real interest in working with
> you to solve this problem upstream, but we need more detailed feedback
> than "too complicated". If you don't like the solutions presented
> thus far, what type of solution would you like to see?
Paul, the design copies the measurement list to a temporary "snapshot"
file, before trimming the measurement list, which according to the
design document locks the existing measurement list. And further
pauses extending the measurement list to calculate the
"snapshot_aggregate".
Userspace can export the measurement list already, so why this
complicated design?
As I mentioned previously and repeated yesterday, the
"snapshot_aggregate" is a new type of critical data and should be
upstreamed independently of this patch set that trims the measurement
list. Trimming the measurement list could be based, as you suggested
on the number of records to remove, or it could be up to the next/last
"snapshot_aggregate" record.
--
thanks,
Mimi
