From: Jeff Layton <jlayton@kernel.org>
To: Stefan Berger <stefanb@linux.ibm.com>,
Christian Brauner <brauner@kernel.org>,
Paul Moore <paul@paul-moore.com>
Cc: zohar@linux.ibm.com, linux-integrity@vger.kernel.org,
miklos@szeredi.hu, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org,
amir73il@gmail.com
Subject: Re: [PATCH] overlayfs: Trigger file re-evaluation by IMA / EVM after writes
Date: Thu, 06 Apr 2023 18:04:36 -0400 [thread overview]
Message-ID: <7d8f05e26dc7152dfad771dfc867dec145aa054b.camel@kernel.org> (raw)
In-Reply-To: <4f739cc6847975991874d56ef9b9716c82cf62a3.camel@kernel.org>
On Thu, 2023-04-06 at 17:24 -0400, Jeff Layton wrote:
> On Thu, 2023-04-06 at 16:22 -0400, Stefan Berger wrote:
> >
> > On 4/6/23 15:37, Jeff Layton wrote:
> > > On Thu, 2023-04-06 at 15:11 -0400, Stefan Berger wrote:
> > > >
> > > > On 4/6/23 14:46, Jeff Layton wrote:
> > > > > On Thu, 2023-04-06 at 17:01 +0200, Christian Brauner wrote:
> > > > > > On Thu, Apr 06, 2023 at 10:36:41AM -0400, Paul Moore wrote:
> > > >
> > > > >
> > > > > Correct. As long as IMA is also measuring the upper inode then it seems
> > > > > like you shouldn't need to do anything special here.
> > > >
> > > > Unfortunately IMA does not notice the changes. With the patch provided in the other email IMA works as expected.
> > > >
> > >
> > >
> > > It looks like remeasurement is usually done in ima_check_last_writer.
> > > That gets called from __fput which is called when we're releasing the
> > > last reference to the struct file.
> > >
> > > You've hooked into the ->release op, which gets called whenever
> > > filp_close is called, which happens when we're disassociating the file
> > > from the file descriptor table.
> > >
> > > So...I don't get it. Is ima_file_free not getting called on your file
> > > for some reason when you go to close it? It seems like that should be
> > > handling this.
> >
> > I would ditch the original proposal in favor of this 2-line patch shown here:
> >
> > https://lore.kernel.org/linux-integrity/a95f62ed-8b8a-38e5-e468-ecbde3b221af@linux.ibm.com/T/#m3bd047c6e5c8200df1d273c0ad551c645dd43232
> >
> >
>
> Ok, I think I get it. IMA is trying to use the i_version from the
> overlayfs inode.
>
> I suspect that the real problem here is that IMA is just doing a bare
> inode_query_iversion. Really, we ought to make IMA call
> vfs_getattr_nosec (or something like it) to query the getattr routine in
> the upper layer. Then overlayfs could just propagate the results from
> the upper layer in its response.
>
> That sort of design may also eventually help IMA work properly with more
> exotic filesystems, like NFS or Ceph.
>
>
>
Maybe something like this? It builds for me but I haven't tested it. It
looks like overlayfs already should report the upper layer's i_version
in getattr, though I haven't tested that either:
-----------------------8<---------------------------
[PATCH] IMA: use vfs_getattr_nosec to get the i_version
IMA currently accesses the i_version out of the inode directly when it
does a measurement. This is fine for most simple filesystems, but can be
problematic with more complex setups (e.g. overlayfs).
Make IMA instead call vfs_getattr_nosec to get this info. This allows
the filesystem to determine whether and how to report the i_version, and
should allow IMA to work properly with a broader class of filesystems in
the future.
Reported-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
security/integrity/ima/ima_api.c | 9 ++++++---
security/integrity/ima/ima_main.c | 12 ++++++++----
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index d3662f4acadc..c45902e72044 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -13,7 +13,6 @@
#include <linux/fs.h>
#include <linux/xattr.h>
#include <linux/evm.h>
-#include <linux/iversion.h>
#include <linux/fsverity.h>
#include "ima.h"
@@ -246,10 +245,11 @@ int ima_collect_measurement(struct integrity_iint_cache *iint,
struct inode *inode = file_inode(file);
const char *filename = file->f_path.dentry->d_name.name;
struct ima_max_digest_data hash;
+ struct kstat stat;
int result = 0;
int length;
void *tmpbuf;
- u64 i_version;
+ u64 i_version = 0;
/*
* Always collect the modsig, because IMA might have already collected
@@ -268,7 +268,10 @@ int ima_collect_measurement(struct integrity_iint_cache *iint,
* to an initial measurement/appraisal/audit, but was modified to
* assume the file changed.
*/
- i_version = inode_query_iversion(inode);
+ result = vfs_getattr_nosec(&file->f_path, &stat, STATX_CHANGE_COOKIE,
+ AT_STATX_SYNC_AS_STAT);
+ if (!result && (stat.result_mask & STATX_CHANGE_COOKIE))
+ i_version = stat.change_cookie;
hash.hdr.algo = algo;
hash.hdr.length = hash_digest_size[algo];
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index d66a0a36415e..365db0e43d7c 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -24,7 +24,6 @@
#include <linux/slab.h>
#include <linux/xattr.h>
#include <linux/ima.h>
-#include <linux/iversion.h>
#include <linux/fs.h>
#include "ima.h"
@@ -164,11 +163,16 @@ static void ima_check_last_writer(struct integrity_iint_cache *iint,
mutex_lock(&iint->mutex);
if (atomic_read(&inode->i_writecount) == 1) {
+ struct kstat stat;
+
update = test_and_clear_bit(IMA_UPDATE_XATTR,
&iint->atomic_flags);
- if (!IS_I_VERSION(inode) ||
- !inode_eq_iversion(inode, iint->version) ||
- (iint->flags & IMA_NEW_FILE)) {
+ if ((iint->flags & IMA_NEW_FILE) ||
+ vfs_getattr_nosec(&file->f_path, &stat,
+ STATX_CHANGE_COOKIE,
+ AT_STATX_SYNC_AS_STAT) ||
+ !(stat.result_mask & STATX_CHANGE_COOKIE) ||
+ stat.change_cookie != iint->version) {
iint->flags &= ~(IMA_DONE_MASK | IMA_NEW_FILE);
iint->measured_pcrs = 0;
if (update)
--
2.39.2
next prev parent reply other threads:[~2023-04-06 22:04 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-05 17:14 [PATCH] overlayfs: Trigger file re-evaluation by IMA / EVM after writes Stefan Berger
2023-04-06 10:26 ` Christian Brauner
2023-04-06 14:05 ` Paul Moore
2023-04-06 14:20 ` Stefan Berger
2023-04-06 14:36 ` Paul Moore
2023-04-06 15:01 ` Christian Brauner
2023-04-06 18:46 ` Jeff Layton
2023-04-06 19:11 ` Stefan Berger
2023-04-06 19:37 ` Jeff Layton
2023-04-06 20:22 ` Stefan Berger
2023-04-06 21:24 ` Jeff Layton
2023-04-06 21:58 ` Stefan Berger
2023-04-06 22:09 ` Jeff Layton
2023-04-06 22:04 ` Jeff Layton [this message]
2023-04-06 22:27 ` Stefan Berger
2023-04-07 8:31 ` Christian Brauner
2023-04-07 13:29 ` Jeff Layton
2023-04-09 15:22 ` Christian Brauner
2023-04-09 22:12 ` Jeff Layton
2023-04-11 8:38 ` Christian Brauner
2023-04-11 9:32 ` Jeff Layton
2023-04-11 9:49 ` Christian Brauner
2023-04-11 10:13 ` Jeff Layton
2023-04-11 14:08 ` Christian Brauner
2023-04-21 14:55 ` Mimi Zohar
2023-04-17 1:57 ` Stefan Berger
2023-04-17 8:11 ` Christian Brauner
2023-04-17 10:05 ` Jeff Layton
2023-04-17 12:45 ` Stefan Berger
2023-04-17 13:18 ` Jeff Layton
2023-04-21 14:43 ` Mimi Zohar
2023-05-18 20:46 ` Paul Moore
2023-05-18 20:50 ` Mimi Zohar
2023-05-19 14:58 ` Paul Moore
2023-05-25 14:43 ` Mimi Zohar
2023-05-19 19:42 ` Mimi Zohar
2023-05-20 9:15 ` Amir Goldstein
2023-05-22 12:18 ` Mimi Zohar
2023-05-22 14:00 ` Amir Goldstein
2023-05-23 19:38 ` Mimi Zohar
2023-05-20 9:17 ` Christian Brauner
2023-05-21 22:49 ` Dave Chinner
2023-05-22 10:50 ` uuid ioctl - was: " Christian Brauner
2023-06-02 1:23 ` Darrick J. Wong
2023-06-02 4:27 ` Theodore Ts'o
2023-06-02 6:34 ` Dave Chinner
2023-06-02 10:53 ` Amir Goldstein
2023-06-02 13:52 ` Christian Brauner
2023-06-02 14:23 ` Darrick J. Wong
2023-06-02 15:34 ` Christian Brauner
2023-06-04 22:59 ` Dave Chinner
2023-06-05 11:37 ` Christian Brauner
2023-06-05 14:36 ` Theodore Ts'o
2023-06-06 0:54 ` Dave Chinner
2023-06-02 14:58 ` Theodore Ts'o
2023-06-04 22:35 ` Dave Chinner
2023-06-02 13:14 ` Christian Brauner
2023-05-23 17:35 ` Mimi Zohar
2023-04-17 14:07 ` Stefan Berger
2023-04-07 6:42 ` Amir Goldstein
2023-04-06 16:10 ` Stefan Berger
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=7d8f05e26dc7152dfad771dfc867dec145aa054b.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=paul@paul-moore.com \
--cc=stefanb@linux.ibm.com \
--cc=zohar@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.