Messages in this thread |  | | From | Andy Lutomirski <> | Date | Thu, 23 Oct 2014 11:32:41 -0700 | Subject | Re: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs only with a mount option |
| |
On Oct 21, 2014 9:59 PM, "Seth Forshee" <seth.forshee@canonical.com> wrote: > > On Tue, Oct 21, 2014 at 02:27:13PM -0700, Andy Lutomirski wrote: > > On Tue, Oct 21, 2014 at 2:21 PM, Seth Forshee > > > > > return s; > > > > > > fail: > > > diff --git a/fs/xattr.c b/fs/xattr.c > > > index 64e83efb742d..383bb9f25555 100644 > > > --- a/fs/xattr.c > > > +++ b/fs/xattr.c > > > @@ -40,6 +40,12 @@ xattr_permission(struct inode *inode, const char *name, int mask) > > > return -EPERM; > > > } > > > > > > + /* Restrict security.* and trusted.* to mounts from init_user_ns. */ > > > + if (inode->i_sb->s_user_ns != &init_user_ns && > > > + (!strcmp(name, XATTR_SECURITY_PREFIX, XATTR_SECURITY_PREFIX_LEN) || > > > + !strcmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN))) > > > + return -EPERM; > > > + > > > > trusted.* should be fine already, I think -- it checks global > > capabilities. And I still think that security.* should be left to > > LSMs, which IMO really do need to be fixed for user namespaces. > > > > But how does this help with FUSE at all? Does FUSE end up calling > > xattr_permission? > > It gets called from vfs_getxattr, and thus for the getxattr syscall for > all fs types, so this would block reading any trusted.* xattrs from the > fuse userspace process.
Oh. It seems weird to me that getxattr would get an error instead of FUSE being prevented from setting those attributes.
I'm still unconvinced that this is the right approach. And anything that tries to use LSMs in a container will eventually want those attributes.
--Andy
|  |