On Thu, Oct 23, 2014 at 11:32:41AM -0700, Andy Lutomirski wrote: > On Oct 21, 2014 9:59 PM, "Seth Forshee" <seth.forshee@xxxxxxxxxxxxx> 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. I suppose so. I'll have to think about this some more. Thanks, Seth -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
