From: Jan Kara <jack@suse.cz>
To: Mark Salyzyn <salyzyn@android.com>
Cc: "Latchesar Ionkov" <lucho@ionkov.net>,
"Dave Kleikamp" <shaggy@kernel.org>,
jfs-discussion@lists.sourceforge.net,
"Phillip Lougher" <phillip@squashfs.org.uk>,
"Jan Kara" <jack@suse.cz>,
linux-integrity@vger.kernel.org,
"Martin Brandenburg" <martin@omnibond.com>,
samba-technical@lists.samba.org,
"Dominique Martinet" <asmadeus@codewreck.org>,
"Chao Yu" <yuchao0@huawei.com>,
"Mimi Zohar" <zohar@linux.ibm.com>,
"Adrian Hunter" <adrian.hunter@intel.com>,
linux-mm@kvack.org, "Chris Mason" <clm@fb.com>,
netdev@vger.kernel.org,
"Andreas Dilger" <adilger.kernel@dilger.ca>,
linux-xfs@vger.kernel.org, "Eric Paris" <eparis@parisplace.org>,
linux-f2fs-devel@lists.sourceforge.net,
linux-afs@lists.infradead.org,
"Stephen Smalley" <sds@tycho.nsa.gov>,
"Mike Marshall" <hubcap@omnibond.com>,
devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org,
"Paul Moore" <paul@paul-moore.com>, "Sage Weil" <sage@redhat.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
"Richard Weinberger" <richard@nod.at>,
"Mark Fasheh" <mark@fasheh.com>,
linux-unionfs@vger.kernel.org, "Hugh Dickins" <hughd@google.com>,
"James Morris" <jmorris@namei.org>,
cluster-devel@redhat.com,
"Joseph Qi" <joseph.qi@linux.alibaba.com>,
"Vyacheslav Dubeyko" <slava@dubeyko.com>,
"Casey Schaufler" <casey@schaufler-ca.com>,
v9fs-developer@lists.sourceforge.net,
"Ilya Dryomov" <idryomov@gmail.com>,
linux-ext4@vger.kernel.org, kernel-team@android.com,
devel@lists.orangefs.org, "Serge Hallyn" <serge@hallyn.com>,
"Gao Xiang" <gaoxiang25@huawei.com>,
"Eric Van Hensbergen" <ericvh@gmail.com>,
ecryptfs@vger.kernel.org, linux-erofs@lists.ozlabs.org,
"Josef Bacik" <josef@toxicpanda.com>,
reiserfs-devel@vger.kernel.org,
"Bob Peterson" <rpeterso@redhat.com>,
"Joel Becker" <jlbec@evilplan.org>,
"Anna Schumaker" <anna.schumaker@netapp.com>,
"David Sterba" <dsterba@suse.com>,
"Jaegeuk Kim" <jaegeuk@kernel.org>,
ceph-devel@vger.kernel.org, selinux@vger.kernel.org,
"Trond Myklebust" <trond.myklebust@hammerspace.com>,
"Andreas Gruenbacher" <agruenba@redhat.com>,
"David Howells" <dhowells@redhat.com>,
linux-nfs@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>,
linux-fsdevel@vger.kernel.org,
"Artem Bityutskiy" <dedekind1@gmail.com>,
"Mathieu Malaterre" <malat@debian.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Miklos Szeredi" <miklos@szeredi.hu>,
"Jeff Layton" <jlayton@kernel.org>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
"Tyler Hicks" <tyhicks@canonical.com>,
"Steve French" <sfrench@samba.org>,
"Ernesto A. Fernández" <ernesto.mnd.fernandez@gmail.com>,
linux-btrfs@vger.kernel.org,
linux-security-module@vger.kernel.org, "Jan Kara" <jack@suse.com>,
"Tejun Heo" <tj@kernel.org>,
linux-mtd@lists.infradead.org,
"Andrew Morton" <akpm@linux-foundation.org>,
"David Woodhouse" <dwmw2@infradead.org>,
"David S. Miller" <davem@davemloft.net>,
ocfs2-devel@oss.oracle.com,
"Alexander Viro" <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v2] Add flags option to get xattr method paired to __vfs_getxattr
Date: Thu, 15 Aug 2019 17:30:24 +0200 [thread overview]
Message-ID: <20190815153024.GP14313@quack2.suse.cz> (raw)
In-Reply-To: <71d66fd1-cc94-fd0c-dfa7-115ba8a6b95a@android.com>
On Wed 14-08-19 07:54:16, Mark Salyzyn wrote:
> On 8/14/19 4:00 AM, Jan Kara wrote:
> > On Tue 13-08-19 07:55:06, Mark Salyzyn wrote:
> > ...
> > > diff --git a/fs/xattr.c b/fs/xattr.c
> > > index 90dd78f0eb27..71f887518d6f 100644
> > > --- a/fs/xattr.c
> > > +++ b/fs/xattr.c
> > ...
> > > ssize_t
> > > __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name,
> > > - void *value, size_t size)
> > > + void *value, size_t size, int flags)
> > > {
> > > const struct xattr_handler *handler;
> > > -
> > > - handler = xattr_resolve_name(inode, &name);
> > > - if (IS_ERR(handler))
> > > - return PTR_ERR(handler);
> > > - if (!handler->get)
> > > - return -EOPNOTSUPP;
> > > - return handler->get(handler, dentry, inode, name, value, size);
> > > -}
> > > -EXPORT_SYMBOL(__vfs_getxattr);
> > > -
> > > -ssize_t
> > > -vfs_getxattr(struct dentry *dentry, const char *name, void *value, size_t size)
> > > -{
> > > - struct inode *inode = dentry->d_inode;
> > > int error;
> > > + if (flags & XATTR_NOSECURITY)
> > > + goto nolsm;
> > Hum, is it OK for XATTR_NOSECURITY to skip even the xattr_permission()
> > check? I understand that for reads of security xattrs it actually does not
> > matter in practice but conceptually that seems wrong to me as
> > XATTR_NOSECURITY is supposed to skip just security-module checks to avoid
> > recursion AFAIU.
>
> Good catch I think.
>
> I was attempting to make this change purely inert, no change in
> functionality, only a change in API. Adding a call to xattr_permission would
> incur a change in overall functionality, as it would introduce into the
> current and original __vfs_getxattr a call to xattr_permission that was not
> there before.
>
> (I will have to defer the real answer and requirements to the security
> folks)
>
> AFAIK you are correct, and to make the call would reduce the attack surface,
> trading a very small amount of CPU utilization, for a much larger amount of
> trust.
>
> Given the long history of this patch set (for overlayfs) and the large
> amount of stakeholders, I would _prefer_ to submit a followup independent
> functionality/security change to _vfs_get_xattr _after_ this makes it in.
You're right. The problem was there before. So ack to changing this later.
> > > diff --git a/include/uapi/linux/xattr.h b/include/uapi/linux/xattr.h
> > > index c1395b5bd432..1216d777d210 100644
> > > --- a/include/uapi/linux/xattr.h
> > > +++ b/include/uapi/linux/xattr.h
> > > @@ -17,8 +17,9 @@
> > > #if __UAPI_DEF_XATTR
> > > #define __USE_KERNEL_XATTR_DEFS
> > > -#define XATTR_CREATE 0x1 /* set value, fail if attr already exists */
> > > -#define XATTR_REPLACE 0x2 /* set value, fail if attr does not exist */
> > > +#define XATTR_CREATE 0x1 /* set value, fail if attr already exists */
> > > +#define XATTR_REPLACE 0x2 /* set value, fail if attr does not exist */
> > > +#define XATTR_NOSECURITY 0x4 /* get value, do not involve security check */
> > > #endif
> > It seems confusing to export XATTR_NOSECURITY definition to userspace when
> > that is kernel-internal flag. I'd just define it in include/linux/xattr.h
> > somewhere from the top of flags space (like 0x40000000).
> >
> > Otherwise the patch looks OK to me (cannot really comment on the security
> > module aspect of this whole thing though).
>
> Good point. However, we do need to keep these flags together to reduce
> maintenance risk, I personally abhor two locations for flags bits even if
> one comes from the opposite bit-side; collisions are undetectable at build
> time. Although I have not gone through the entire thought experiment, I am
> expecting that fuse could possibly benefit from this flag (if exposed) since
> it also has a security recursion. That said, fuse is probably the example of
> a gaping wide attack surface if user space had access to it ... your
> xattr_permissions call addition requested above would be realistically, not
> just pedantically, required!
Yeah, flags bits in two places are bad as well. So maybe at least
#ifdef __KERNEL__ bit around the definitiona and a comment that it is
kernel internal flag?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-08-15 15:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-13 14:55 [PATCH v2] Add flags option to get xattr method paired to __vfs_getxattr Mark Salyzyn
2019-08-14 5:57 ` kbuild test robot
2019-08-14 11:00 ` Jan Kara
2019-08-14 14:54 ` Mark Salyzyn
2019-08-15 15:30 ` Jan Kara [this message]
2019-08-14 11:59 ` kbuild test robot
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=20190815153024.GP14313@quack2.suse.cz \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=adrian.hunter@intel.com \
--cc=agruenba@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=anna.schumaker@netapp.com \
--cc=asmadeus@codewreck.org \
--cc=casey@schaufler-ca.com \
--cc=ceph-devel@vger.kernel.org \
--cc=clm@fb.com \
--cc=cluster-devel@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=davem@davemloft.net \
--cc=dedekind1@gmail.com \
--cc=devel@driverdev.osuosl.org \
--cc=devel@lists.orangefs.org \
--cc=dhowells@redhat.com \
--cc=dsterba@suse.com \
--cc=dwmw2@infradead.org \
--cc=ecryptfs@vger.kernel.org \
--cc=eparis@parisplace.org \
--cc=ericvh@gmail.com \
--cc=ernesto.mnd.fernandez@gmail.com \
--cc=gaoxiang25@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=hubcap@omnibond.com \
--cc=hughd@google.com \
--cc=idryomov@gmail.com \
--cc=jack@suse.com \
--cc=jaegeuk@kernel.org \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=jlayton@kernel.org \
--cc=jlbec@evilplan.org \
--cc=jmorris@namei.org \
--cc=josef@toxicpanda.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=kernel-team@android.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=malat@debian.org \
--cc=mark@fasheh.com \
--cc=martin@omnibond.com \
--cc=miklos@szeredi.hu \
--cc=netdev@vger.kernel.org \
--cc=ocfs2-devel@oss.oracle.com \
--cc=paul@paul-moore.com \
--cc=phillip@squashfs.org.uk \
--cc=reiserfs-devel@vger.kernel.org \
--cc=richard@nod.at \
--cc=rpeterso@redhat.com \
--cc=sage@redhat.com \
--cc=salyzyn@android.com \
--cc=samba-technical@lists.samba.org \
--cc=sds@tycho.nsa.gov \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=sfrench@samba.org \
--cc=shaggy@kernel.org \
--cc=slava@dubeyko.com \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
--cc=trond.myklebust@hammerspace.com \
--cc=tyhicks@canonical.com \
--cc=tytso@mit.edu \
--cc=v9fs-developer@lists.sourceforge.net \
--cc=viro@zeniv.linux.org.uk \
--cc=yuchao0@huawei.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).