From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>,
Miklos Szeredi <miklos@szeredi.hu>
Cc: Alban Crequy <alban@kinvolk.io>, Dongsu Park <dongsu@kinvolk.io>,
linux-integrity <linux-integrity@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC PATCH] ima: force the re-evaluation of files on untrusted file systems
Date: Mon, 05 Feb 2018 15:50:58 +0000 [thread overview]
Message-ID: <1517845858.3050.13.camel@HansenPartnership.com> (raw)
In-Reply-To: <1517838054.3736.49.camel@linux.vnet.ibm.com>
On Mon, 2018-02-05 at 08:40 -0500, Mimi Zohar wrote:
> On filesystems, such as fuse or remote filesystems, that we can not
> detect or rely on the filesystem to tell us when a file has changed,
> always re-measure, re-appraise, and/or re-audit the file.
Using the presence or absence of d_revalidate isn't definitive for
uncacheable appraisals: all stacked filesystems have to implement
d_revalidate just in case the underlying has it, but it doesn't mean
their appraisals can't be cached if they're fully built on top of
traditional filesystems (like they are in the Docker/OCI use case). I
think the original flag approach is better. The only thing stackable
filesystems argues for is that for them it should probably be a
superblock flag so it can be per-mount point (depending on overlay
composition).
d_revalidate() also strikes me as wrong from the semantic point of
view: it's about whether the path name to inode cache needs re-
evaluating not whether the underlying inode could change arbitrarily.
These are definitely related but not necessarily equivalent concepts.
James
next prev parent reply other threads:[~2018-02-05 15:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1517838054.3736.49.camel@linux.vnet.ibm.com>
2018-02-05 14:24 ` [RFC PATCH] ima: force the re-evaluation of files on untrusted file systems Alban Crequy
2018-02-05 15:50 ` James Bottomley [this message]
2018-02-05 16:12 ` Miklos Szeredi
2018-02-05 16:21 ` Mimi Zohar
2018-02-05 16:30 ` Miklos Szeredi
2018-02-05 16:37 ` Mimi Zohar
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=1517845858.3050.13.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=alban@kinvolk.io \
--cc=dongsu@kinvolk.io \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=zohar@linux.vnet.ibm.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