From: Christian Brauner <christian.brauner@ubuntu.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Paul Moore <paul@paul-moore.com>, Jan Kara <jack@suse.cz>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>,
"J. Bruce Fields" <bfields@fieldses.org>,
Tyler Hicks <code@tyhicks.com>, James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
LSM List <linux-security-module@vger.kernel.org>
Subject: Re: LSM and setxattr helpers
Date: Mon, 5 Apr 2021 14:23:20 +0200 [thread overview]
Message-ID: <20210405122320.qnjiqlyvzkb2xxi2@wittgenstein> (raw)
In-Reply-To: <CAOQ4uxg+82RLt+KZXVLYhuDvrPLE0zaLf3Nw=oCJ=wBY6j6hTw@mail.gmail.com>
On Sun, Apr 04, 2021 at 01:27:21PM +0300, Amir Goldstein wrote:
> [forking question about security modules]
>
> >
> > Nice thing about vfs_{set,remove}xattr() is that they already have
> > several levels of __vfs_ helpers and nfsd already calls those, so
> > we can hoist fsnotify_xattr() hooks hooks up from the __vfs_xxx
> > helpers to the common vfs_xxx helpers and add fsnotify hooks to
> > the very few callers of __vfs_ helpers.
> >
> > nfsd is consistently calling __vfs_{set,remove}xattr_locked() which
> > do generate events, but ecryptfs mixes __vfs_setxattr_locked() with
> > __vfs_removexattr(), which does not generate event and does not
> > check permissions - it looks like an oversight.
> >
> > The thing is, right now __vfs_setxattr_noperm() generates events,
> > but looking at all the security/* callers, it feels to me like those are
> > very internal operations and that "noperm" should also imply "nonotify".
> >
> > To prove my point, all those callers call __vfs_removexattr() which
> > does NOT generate an event.
> >
> > Also, I *think* the EVM setxattr is something that usually follows
> > another file data/metadata change, so some event would have been
> > generated by the original change anyway.
> >
> > Mimi,
> >
> > Do you have an opinion on that?
> >
> > The question is if you think it is important for an inotify/fanotify watcher
> > that subscribed to IN_ATTRIB/FAN_ATTRIB events on a file to get an
> > event when the IMA security blob changes.
> >
>
> Guys,
>
> I was doing some re-factoring of the __vfs_setxattr helpers
> and noticed some strange things.
>
> The wider context is fsnotify_xattr() hooks inside internal
> setxattr,removexattr calls. I would like to move those hooks
> to the common vfs_{set,remove}xattr() helpers.
>
> SMACK & SELINUX:
> For the callers of __vfs_setxattr_noperm(),
> smack_inode_setsecctx() and selinux_inode_setsecctx()
> It seems that the only user is nfsd4_set_nfs4_label(), so it
> makes sense for me to add the fsnotify_xattr() in nfsd context,
> same as I did with other fsnotify_ hooks.
>
> Are there any other expected callers of security_inode_setsecctx()
> except nfsd in the future? If so they would need to also add the
> fsnotify_xattr() hook, if at all the user visible FS_ATTRIB event is
> considered desirable.
>
> SMACK:
> Just to be sure, is the call to __vfs_setxattr() from smack_d_instantiate()
> guaranteed to be called for an inode whose S_NOSEC flag is already
> cleared? Because the flag is being cleared by __vfs_setxattr_noperm().
>
> EVM:
> I couldn't find what's stopping this recursion:
> evm_update_evmxattr() => __vfs_setxattr_noperm() =>
> security_inode_post_setxattr() => evm_inode_post_removexattr() =>
> evm_update_evmxattr()
>
> It looks like the S_NOSEC should already be clear when
> evm_update_evmxattr() is called(?), so it seems more logical to me to
> call __vfs_setxattr() as there is no ->inode_setsecurity() hook for EVM.
> Am I missing something?
>
> It seems to me that updating the EVM hmac should not generate
> a visible FS_ATTRIB event to listeners, because it is an internal
> implementation detail and because update EVM hmac happens
> following another change to the inode which anyway reports a
> visible event to listeners.
> Also, please note that evm_update_evmxattr() may also call
> __vfs_removexattr() which does not call the fsnotify_xattr() hook.
>
> IMA:
> Similarly, ima_fix_xattr() should be called on an inode without
> S_NOSEC flag and no other LSM should be interested in the
> IMA hash update, right? So wouldn't it be better to use
> __vfs_setxattr() in this case as well?
It feels like xattr changes that are essentially side-effects of another
operation should probably not generate fsnotify() events in general; at
least not without a good reason why userspace needs to know about the
event.
Christian
next prev parent reply other threads:[~2021-04-05 12:23 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-28 15:56 [RFC][PATCH] fanotify: allow setting FAN_CREATE in mount mark mask Amir Goldstein
2021-03-30 7:31 ` Christian Brauner
2021-03-30 9:31 ` Amir Goldstein
2021-03-30 16:24 ` Amir Goldstein
2021-03-31 10:08 ` Christian Brauner
2021-03-31 10:57 ` Amir Goldstein
2021-04-08 11:44 ` open_by_handle_at() in userns Amir Goldstein
2021-04-08 12:55 ` Christian Brauner
2021-04-08 14:15 ` J. Bruce Fields
2021-04-08 15:54 ` Amir Goldstein
2021-04-08 16:08 ` J. Bruce Fields
2021-04-08 16:48 ` Frank Filz
2021-04-08 15:34 ` Amir Goldstein
2021-04-08 15:41 ` Christian Brauner
2021-03-30 12:12 ` [RFC][PATCH] fanotify: allow setting FAN_CREATE in mount mark mask Christian Brauner
2021-03-30 12:33 ` Amir Goldstein
2021-03-30 12:53 ` Christian Brauner
2021-03-30 12:55 ` Christian Brauner
2021-03-30 13:54 ` Amir Goldstein
2021-03-30 14:17 ` Christian Brauner
2021-03-30 14:56 ` Amir Goldstein
2021-03-31 9:46 ` Christian Brauner
2021-03-31 11:29 ` Amir Goldstein
2021-03-31 12:17 ` Christian Brauner
2021-03-31 12:59 ` Amir Goldstein
2021-03-31 12:54 ` Jan Kara
2021-03-31 14:06 ` Amir Goldstein
2021-03-31 20:59 ` fsnotify path hooks Amir Goldstein
2021-04-01 10:29 ` Jan Kara
2021-04-01 14:18 ` Amir Goldstein
2021-04-02 8:20 ` Amir Goldstein
2021-04-04 10:27 ` LSM and setxattr helpers Amir Goldstein
2021-04-05 12:23 ` Christian Brauner [this message]
2021-04-05 14:47 ` Mimi Zohar
2021-04-06 15:43 ` Amir Goldstein
2021-04-05 16:18 ` Casey Schaufler
2021-04-06 8:35 ` fsnotify path hooks Jan Kara
2021-04-06 18:49 ` Amir Goldstein
2021-04-08 12:52 ` Jan Kara
2021-04-08 15:11 ` Amir Goldstein
2021-04-09 10:08 ` Jan Kara
2021-04-09 10:45 ` Christian Brauner
2021-04-20 6:01 ` Amir Goldstein
2021-04-20 11:41 ` Christian Brauner
2021-04-20 11:58 ` Amir Goldstein
2021-04-20 13:38 ` Christian Brauner
2021-04-09 13:22 ` Amir Goldstein
2021-04-09 14:30 ` Al Viro
2021-04-09 14:39 ` Christian Brauner
2021-04-09 14:46 ` Al Viro
2021-04-09 15:20 ` Christian Brauner
2021-04-09 16:06 ` Amir Goldstein
2021-04-09 16:09 ` Amir Goldstein
2021-04-18 18:51 ` Amir Goldstein
2021-04-19 8:08 ` Amir Goldstein
2021-04-19 16:41 ` Amir Goldstein
2021-04-19 17:02 ` Al Viro
2021-04-19 22:04 ` Amir Goldstein
2021-04-20 7:53 ` Amir Goldstein
2021-03-31 13:06 ` [RFC][PATCH] fanotify: allow setting FAN_CREATE in mount mark mask J. Bruce Fields
2021-03-30 12:20 ` Amir Goldstein
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=20210405122320.qnjiqlyvzkb2xxi2@wittgenstein \
--to=christian.brauner@ubuntu.com \
--cc=amir73il@gmail.com \
--cc=bfields@fieldses.org \
--cc=casey@schaufler-ca.com \
--cc=code@tyhicks.com \
--cc=jack@suse.cz \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.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).