From: Stefan Berger <stefanb@linux.ibm.com>
To: Jeff Layton <jlayton@kernel.org>,
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, 6 Apr 2023 16:22:43 -0400 [thread overview]
Message-ID: <d61ed13b-0fd2-0283-96d2-0ff9c5e0a2f9@linux.ibm.com> (raw)
In-Reply-To: <60339e3bd08a18358ac8c8a16dc67c74eb8ba756.camel@kernel.org>
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
The new proposed i_version increase occurs on the inode that IMA sees later on for
the file that's being executed and on which it must do a re-evaluation.
Upon file changes ima_inode_free() seems to see two ima_file_free() calls,
one for what seems to be the upper layer (used for vfs_* functions below)
and once for the lower one.
The important thing is that IMA will see the lower one when the file gets
executed later on and this is the one that I instrumented now to have its
i_version increased, which in turn triggers the re-evaluation of the file post
modification.
static ssize_t ovl_write_iter(struct kiocb *iocb, struct iov_iter *iter)
[...]
struct fd real;
[...]
ret = ovl_real_fdget(file, &real);
if (ret)
goto out_unlock;
[...]
if (is_sync_kiocb(iocb)) {
file_start_write(real.file);
--> ret = vfs_iter_write(real.file, iter, &iocb->ki_pos,
ovl_iocb_to_rwf(ifl));
file_end_write(real.file);
/* Update size */
ovl_copyattr(inode);
} else {
struct ovl_aio_req *aio_req;
ret = -ENOMEM;
aio_req = kmem_cache_zalloc(ovl_aio_request_cachep, GFP_KERNEL);
if (!aio_req)
goto out;
file_start_write(real.file);
/* Pacify lockdep, same trick as done in aio_write() */
__sb_writers_release(file_inode(real.file)->i_sb,
SB_FREEZE_WRITE);
aio_req->fd = real;
real.flags = 0;
aio_req->orig_iocb = iocb;
kiocb_clone(&aio_req->iocb, iocb, real.file);
aio_req->iocb.ki_flags = ifl;
aio_req->iocb.ki_complete = ovl_aio_rw_complete;
refcount_set(&aio_req->ref, 2);
--> ret = vfs_iocb_iter_write(real.file, &aio_req->iocb, iter);
ovl_aio_put(aio_req);
if (ret != -EIOCBQUEUED)
ovl_aio_cleanup_handler(aio_req);
}
if (ret > 0) <--- this get it to work
inode_maybe_inc_iversion(inode, false); <--- since this inode is known to IMA
out:
revert_creds(old_cred);
out_fdput:
fdput(real);
out_unlock:
inode_unlock(inode);
Stefan
>
> In any case, I think this could use a bit more root-cause analysis.
next prev parent reply other threads:[~2023-04-06 20:23 UTC|newest]
Thread overview: 46+ 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 [this message]
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
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-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=d61ed13b-0fd2-0283-96d2-0ff9c5e0a2f9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).