From: Mimi Zohar <zohar@linux.ibm.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Sush Shringarputale <sushring@linux.microsoft.com>,
linux-integrity@vger.kernel.org, peterhuewe@gmx.de,
jarkko@kernel.org, jgg@ziepe.ca, kgold@linux.ibm.com,
bhe@redhat.com, vgoyal@redhat.com, dyoung@redhat.com,
kexec@lists.infradead.org, jmorris@namei.org, serge@hallyn.com,
code@tyhicks.com, nramas@linux.microsoft.com,
Tushar Sugandhi <tusharsu@linux.mic>,
linux-security-module@vger.kernel.org,
AmirGoldstein <amir73il@gmail.com>
Subject: Re: [RFC] IMA Log Snapshotting Design Proposal
Date: Wed, 30 Aug 2023 17:50:12 -0400 [thread overview]
Message-ID: <2d800c3c0b6b4908843b490c36ef9df0cb4da134.camel@linux.ibm.com> (raw)
In-Reply-To: <CAHC9VhStr3BAzb3tyHzHVPXzzuxyXjPQ4vmi+SrJqbTWio04+Q@mail.gmail.com>
On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote:
> On Wed, Aug 30, 2023 at 4:25 PM Mimi Zohar <zohar@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.
>
> > 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
next prev parent reply other threads:[~2023-08-30 21:52 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 19:12 [RFC] IMA Log Snapshotting Design Proposal Sush Shringarputale
2023-08-01 21:21 ` James Bottomley
2023-08-07 22:49 ` Stefan Berger
2023-08-08 12:35 ` James Bottomley
2023-08-08 13:31 ` Stefan Berger
2023-08-08 18:26 ` James Bottomley
2023-08-08 20:09 ` Stefan Berger
2023-08-08 21:41 ` James Bottomley
2023-08-10 4:43 ` Tushar Sugandhi
2023-08-10 11:43 ` James Bottomley
2023-08-11 15:48 ` Tushar Sugandhi
2023-08-10 4:31 ` Tushar Sugandhi
2023-08-10 4:29 ` Tushar Sugandhi
2023-08-10 1:23 ` Tushar Sugandhi
2023-08-10 1:15 ` Tushar Sugandhi
2023-08-10 14:12 ` Stefan Berger
2023-08-11 15:57 ` Tushar Sugandhi
2023-08-11 18:16 ` Stefan Berger
2023-08-10 1:03 ` Tushar Sugandhi
2023-08-11 13:14 ` Mimi Zohar
2023-08-14 21:42 ` Sush Shringarputale
2023-08-14 22:02 ` Mimi Zohar
2023-08-21 22:05 ` Sush Shringarputale
2023-08-21 23:07 ` Mimi Zohar
2023-08-29 19:34 ` Paul Moore
2023-08-29 21:03 ` Mimi Zohar
2023-08-29 21:30 ` Paul Moore
2023-08-29 21:54 ` Mimi Zohar
2023-08-29 23:15 ` Paul Moore
2023-08-30 20:25 ` Mimi Zohar
2023-08-30 20:47 ` Paul Moore
2023-08-30 21:50 ` Mimi Zohar [this message]
2023-08-30 22:21 ` Paul Moore
2023-08-30 22:23 ` Paul Moore
2023-08-30 23:06 ` Mimi Zohar
2023-08-30 23:22 ` Paul Moore
2023-08-31 14:01 ` Mimi Zohar
2023-08-31 14:43 ` Paul Moore
2023-08-31 16:46 ` Dr. Greg
2023-08-31 17:56 ` Paul Moore
2023-08-30 18:06 ` [RFC] IMA Log Snapshotting Design Proposal - network bandwidth Ken Goldman
2023-09-01 21:20 ` Tushar Sugandhi
2023-09-06 20:20 ` Ken Goldman
2023-09-07 20:40 ` Paul Moore
2023-08-30 18:12 ` [RFC] IMA Log Snapshotting Design Proposal - aggregate Ken Goldman
2023-09-01 22:06 ` Tushar Sugandhi
2023-09-06 20:49 ` Ken Goldman
2023-09-07 21:02 ` Paul Moore
2023-08-30 19:12 ` [RFC] IMA Log Snapshotting Design Proposal - unseal Ken Goldman
2023-08-31 15:54 ` Dr. Greg
2023-09-01 21:22 ` Tushar Sugandhi
2023-09-06 20:13 ` Ken Goldman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2d800c3c0b6b4908843b490c36ef9df0cb4da134.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=amir73il@gmail.com \
--cc=bhe@redhat.com \
--cc=code@tyhicks.com \
--cc=dyoung@redhat.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=jmorris@namei.org \
--cc=kexec@lists.infradead.org \
--cc=kgold@linux.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=nramas@linux.microsoft.com \
--cc=paul@paul-moore.com \
--cc=peterhuewe@gmx.de \
--cc=serge@hallyn.com \
--cc=sushring@linux.microsoft.com \
--cc=tusharsu@linux.mic \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox