All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: Jeff Layton <jlayton@kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	Amir Goldstein <amir73il@gmail.com>
Cc: Paul Moore <paul@paul-moore.com>,
	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
Subject: Re: [PATCH] overlayfs: Trigger file re-evaluation by IMA / EVM after writes
Date: Mon, 17 Apr 2023 08:45:40 -0400	[thread overview]
Message-ID: <176640ae-3ff7-c3e9-218a-2952425336e7@linux.ibm.com> (raw)
In-Reply-To: <94c2aadfb2fe7830d0289ffe6084581b99505a58.camel@kernel.org>



On 4/17/23 06:05, Jeff Layton wrote:
> On Sun, 2023-04-16 at 21:57 -0400, Stefan Berger wrote:
>>
>> On 4/7/23 09:29, Jeff Layton wrote:

>>>
>>> Note that there Stephen is correct that calling getattr is probably
>>> going to be less efficient here since we're going to end up calling
>>> generic_fillattr unnecessarily, but I still think it's the right thing
>>> to do.
>>
>> I was wondering whether to use the existing inode_eq_iversion() for all
>> other filesystems than overlayfs, nfs, and possibly other ones (which ones?)
>> where we would use the vfs_getattr_nosec() via a case on inode->i_sb->s_magic?
>> If so, would this function be generic enough to be a public function for libfs.c?
>>
>> I'll hopefully be able to test the proposed patch tomorrow.
>>
>>
> 
> No, you don't want to use inode_eq_iversion here because (as the comment
> over it says):

In the ima_check_last_writer() case the usage of inode_eq_iversion() was correct since
at this point no record of  its value was made and therefore no writer needed to change
the i_value again due to IMA:

		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)) {
			iint->flags &= ~(IMA_DONE_MASK | IMA_NEW_FILE);
			iint->measured_pcrs = 0;
			if (update)
				ima_update_xattr(iint, file);
		}

The record of the value is only made when the actual measurement is done in
ima_collect_measurement()

Compared to this the usage of vfs_getattr_nosec() is expensive since it resets the flag.

         if ((request_mask & STATX_CHANGE_COOKIE) && IS_I_VERSION(inode)) {
                 stat->result_mask |= STATX_CHANGE_COOKIE;
                 stat->change_cookie = inode_query_iversion(inode);
         }

	idmap = mnt_idmap(path->mnt);
	if (inode->i_op->getattr)
		return inode->i_op->getattr(idmap, path, stat,
					    request_mask, query_flags);

Also, many filesystems will have their getattr now called as well.

I understand Christian's argument about the maintenance headache to a certain degree...

    Stefan

> 
>   * Note that we don't need to set the QUERIED flag in this case, as the value
>   * in the inode is not being recorded for later use.
> 
> The IMA code _does_ record the value for later use. Furthermore, it's
> not valid to use inode_eq_iversion on a non-IS_I_VERSION inode, so it's
> better to just use vfs_getattr_nosec which allows IMA to avoid all of
> those gory details.
> 
> Thanks,

  reply	other threads:[~2023-04-17 12:45 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
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 [this message]
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=176640ae-3ff7-c3e9-218a-2952425336e7@linux.ibm.com \
    --to=stefanb@linux.ibm.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jlayton@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=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.