public inbox for linux-integrity@vger.kernel.org
 help / color / mirror / Atom feed
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


  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