Re: [RFC] IMA Log Snapshotting Design Proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote:
> On Wed, Aug 30, 2023 at 4:25 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> 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.

> 
> > In the
> > "snapshotting" design this problem becomes a userspace issue.
> 
> Yes, exactly.  Userspace is almost always going to have an easier time
> recovering from these types of errors ... or at least I believe so,
> perhaps you have a clever solution for how the kernel can handle the
> file/filesystem disappearing from under the fd?

Nothing changes.  New measurements are initially stored in kernel
memory, until they are successfully copied.

> > The first sentence of the cover letter is "Depending on the IMA policy,
> > the IMA log can consume a lot of Kernel memory on the device." ...
> 
> As I'm still looking for an answer to my question, let's stay focused
> on that before we start worrying too much about the phrasing of the
> design proposal that was submitted.

It's more than just phrasing, but the purpose/motivation of the
proposed changes.

--  
thanks,

Mimi


_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux