[RFC] IMA Log Snapshotting Design Proposal

Paul Moore paul at paul-moore.com
Wed Aug 30 23:22:27 UTC 2023


On Wed, Aug 30, 2023 at 7:07 PM Mimi Zohar <zohar at linux.ibm.com> wrote:
> On Wed, 2023-08-30 at 18:23 -0400, Paul Moore wrote:
> > On Wed, Aug 30, 2023 at 6:21 PM Paul Moore <paul at paul-moore.com> wrote:
> > > On Wed, Aug 30, 2023 at 5:50 PM Mimi Zohar <zohar at linux.ibm.com> wrote:
> > > > On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote:
> > > > > On Wed, Aug 30, 2023 at 4:25 PM Mimi Zohar <zohar at linux.ibm.com> wrote:
> > > > > > Your initial question was "what happens if the file/filesystem becomes
> > > > > > inaccessible at some point and an attestation client attempts to read
> > > > > > the entire log?".  For what reason would it be inaccessible?  For the
> > > > > > original single tmpfs file, what would make it inaccessible?
> > > > >
> > > > > In your reply that I had responded to you had mentioned that the
> > > > > kernel was simply being passed a fd and taking ownership of it, the fd
> > > > > could either be a tmpfs backed file or some form of persistent storage
> > > > > as both were discussed in this thread.  I imagine a tmpfs filesystem
> > > > > could still be forcibly unmounted, resulting in problems, but I can't
> > > > > say that for certain.  However, there are definitely cases where a fd
> > > > > backed against an arbitrary filesystem could run into problems:
> > > > > storage device issues for local filesystems, networking issues for
> > > > > network filesystems, and good old fashioned user/admin intervention in
> > > > > both cases.
> > > >
> > > > "I imagine tmpfs filesystem could still be forcibly unmounted" sounds
> > > > like an attack. Not being able to verify the measurement list against a
> > > > quote is probably a good thing.
> > >
> > > Okay, can you answer the question for an arbitrary persistent
> > > filesystem?  That was always the more important question, ...
>
> The original proposal, not mine, suggested using a tmpfs file.   The
> idea of writing the measurements to a file on a persistent filesystem
> wasn't mine either.  Sush/Tushar were pushing for writing to a
> persistent file(s).  No argument from me that writing to a file on an
> arbitrary persistent filesystem is not a good idea.

Progress.  Okay, so we all now agree that the kernel writing to an
arbitrary filesystem is not a good idea, and using tmpfs doesn't solve
the problem of general memory pressure (from previously in this
thread), that's all helpful and good to clarify.

Assuming Sush and Tushar rework the document to clarify the
motivation/purpose for the work, as you suggested earlier, I'm
assuming we can revisit this problem and solutions?

-- 
paul-moore.com



More information about the Linux-security-module-archive mailing list