Re: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs only with a mount option

From: Michael j Theall
Date: Tue Oct 21 2014 - 17:34:22 EST


Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote on 10/21/2014 04:27:13 PM:

> From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
> To: Andy Lutomirski <luto@xxxxxxxxxxxxxx>, "Eric W. Biederman"
> <ebiederm@xxxxxxxxxxxx>, Michael j Theall/Houston/IBM@IBMUS, fuse-
> devel@xxxxxxxxxxxxxxxxxxxxx, Linux FS Devel <linux-
> fsdevel@xxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-
> kernel@xxxxxxxxxxxxxxx>, Miklos Szeredi <miklos@xxxxxxxxxx>, "Serge
> H. Hallyn" <serge.hallyn@xxxxxxxxxx>
> Date: 10/21/2014 04:27 PM
> Subject: Re: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged
> xattrs only with a mount option
>
> On Tue, Oct 21, 2014 at 2:21 PM, Seth Forshee
> <seth.forshee@xxxxxxxxxxxxx> wrote:
> > On Wed, Oct 15, 2014 at 07:37:36AM -0700, Andy Lutomirski wrote:
> >> On Wed, Oct 15, 2014 at 12:39 AM, Seth Forshee
> >> <seth.forshee@xxxxxxxxxxxxx> wrote:
> >> > On Tue, Oct 14, 2014 at 02:19:19PM -0700, Andy Lutomirski wrote:
> >> >> On Tue, Oct 14, 2014 at 2:13 PM, Eric W. Biederman
> >> >> <ebiederm@xxxxxxxxxxxx> wrote:
> >> >> > Seth Forshee <seth.forshee@xxxxxxxxxxxxx> writes:
> >> >> >
> >> >> >> On Tue, Oct 14, 2014 at 01:01:02PM -0700, Eric W. Biederman
wrote:
> >> >> >>> Michael j Theall <mtheall@xxxxxxxxxx> writes:
> >> >> >>>
> >> >> >>> > Seth Forshee <seth.forshee@xxxxxxxxxxxxx> wrote on 10/
> 14/2014 09:25:55 AM:
> >> >> >>> >
> >> >> >>> >> From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
> >> >> >>> >> To: Miklos Szeredi <miklos@xxxxxxxxxx>
> >> >> >>> >> Cc: fuse-devel@xxxxxxxxxxxxxxxxxxxxx, "Serge H. Hallyn"
> >> >> >>> >> <serge.hallyn@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx,
Seth
> >> >> >>> >> Forshee <seth.forshee@xxxxxxxxxxxxx>, "Eric W. Biederman"
> >> >> >>> >> <ebiederm@xxxxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx
> >> >> >>> >> Date: 10/14/2014 09:27 AM
> >> >> >>> >> Subject: [fuse-devel] [PATCH v4 4/5] fuse: Support
> privileged xattrs
> >> >> >>> >> only with a mount option
> >> >> >>> >>
> >> >> >>> >> Allowing unprivileged users to provide arbitrary xattrs via
fuse
> >> >> >>> >> mounts bypasses the normal restrictions on setting xattrs.
Such
> >> >> >>> >> mounts should be restricted to reading and writing xattrs
in the
> >> >> >>> >> user.* namespace.
> >> >> >>> >>
> >> >> >>> >
> >> >> >>> > Can you explain how the normal restrictions on setting
xattrs are
> >> >> >>> > bypassed?
> >> >> >>>
> >> >> >>> If the fuse server is not run by root. Which is a large part
of the
> >> >> >>> point of fuse.
> >> >> >>
> >> >> >> So the server could for example return trusted.* xattrs
> which were not
> >> >> >> set by a privileged user.
> >> >> >>
> >> >> >>> > My filesystem still needs security.* and system.*, and
> it looks like
> >> >> >>> > xattr_permission already prevents non-privileged users
> from accessing
> >> >> >>> > trusted.*
> >> >> >>>
> >> >> >>> If the filesystem is mounted with nosuid (typical of a
> non-privileged
> >> >> >>> mount of fuse) then the security.* attributes are ignored.
> >> >> >>
> >> >> >> That I wasn't aware of. In fact I still haven't found where
this
> >> >> >> restriction is implemented.
> >> >> >
> >> >> > My memory may be have been incomplete. What I was thinking of
is
> >> >> > security/commoncap.c the MNT_NOSUID check in get_file_caps.
> >> >> >
> >> >> > Upon inspection that appears limited to file capabilities, and
while
> >> >> > there are a few other MNT_NOSUID checks under security the
> feel far from
> >> >> > complete.
> >> >> >
> >> >> > Sigh.
> >> >> >
> >> >> > This deserves a hard look because if MNT_NOSUID is not
sufficient than
> >> >> > it may be possible for me to insert a usb stick with an
extNfilesystem
> >> >> > with the right labels having it auto-mounted nosuid and subvert
the
> >> >> > security of something like selinux.
> >> >>
> >> >> It's this code in selinux/hooks.c:
> >> >>
> >> >> if ((bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID) ||
> >> >> (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))
> >> >> new_tsec->sid = old_tsec->sid;
> >> >>
> >> >>
> >> >> One might argue that this should actually generate -EPERM instead
of
> >> >> ignoring the label, but it should be safe against untrusted media.
> >> >>
> >> >> >
> >> >> >> Nonetheless, a userns mount could be done without nosuid
(though that
> >> >> >> mount will also be unaccessible outside of that namespace).
> >> >> >>
> >> >> >>> >> It's difficult though to tell whether a mount is being
performed
> >> >> >>> >> on behalf of an unprivileged user since fuse mounts are
ususally
> >> >> >>> >> done via a suid root helper. Thus a new mount option,
> >> >> >>> >> privileged_xattrs, is added to indicated that xattrs from
other
> >> >> >>> >> namespaces are allowed. This option can only be supplied by
> >> >> >>> >> system-wide root; supplying the option as an unprivileged
user
> >> >> >>> >> will cause the mount to fail.
> >> >> >>> >
> >> >> >>> > I can't say I'm convinced that this is the right
> direction to head.
> >> >> >>>
> >> >> >>> With respect to defaults we could keep the current default if
you
> >> >> >>> have the global CAP_SYS_ADMIN privilege when the mount takes
place
> >> >> >>> and then avoid breaking anything.
> >> >> >>
> >> >> >> Except that unprivileged mounts are normally done by a suid
> root helper,
> >> >> >> which is why I've required both global CAP_SYS_ADMIN and a
> mount option
> >> >> >> to get the current default behavior.
> >> >> >
> >> >> > If nosuid is sufficient that may break existing setups for no
good
> >> >> > reason.
> >> >> >
> >> >> > Shrug. I won't have much time for a bit but I figured I
> would highlight
> >> >> > the potential security hole in existing setups. So someone with
time
> >> >> > this week can look at that.
> >> >>
> >> >> I think I have a better solution. I'll send it out.
> >> >
> >> > To be honest I don't understand enough about how selinux uses
security
> >> > labels to know what level of paranoia is appropriate, so I wrote
this
> >> > out of an excess of paranoia. If the patch you sent restricts
things
> >> > sufficiently then I'm perfectly happy to see this patch dropped.
> >> >
> >> > And really with fuse all of this is really excess paranoia because
(if
> >> > my other patches are applied at least) the fuse mount will be
> >> > inaccessible to any user outside the user namespace from which it
was
> >> > mounted or its descendants.
> >> >
> >>
> >> I missed the rest of the series. This is exciting!
> >>
> >> I'm not sure that the other protections you have are quite
sufficient,
> >> though, without something like my patch. I'll comment on the rest.
> >
> > I still suspect we should be doing more to limit xattrs from userns
> > mounts, since normally only root is allowed to set trusted.* and
> > security.* xattrs. Seems like this should be done more generally
though
> > and not just specific to fuse. Something like this maybe? It probably
> > won't matter much for fuse mounts since they won't be accessible
outside
> > the userns which did the mount, but for other filesystems the xattrs
> > could be set externally and injected into the system via a userns
mount.
> >
> >
> > diff --git a/fs/super.c b/fs/super.c
> > index eae088f6aaae..499cd7d2d2f8 100644
> > --- a/fs/super.c
> > +++ b/fs/super.c
> > @@ -149,6 +149,7 @@ static void destroy_super(struct super_block *s)
> > percpu_counter_destroy(&s->s_writers.counter[i]);
> > security_sb_free(s);
> > WARN_ON(!list_empty(&s->s_mounts));
> > + put_user_ns(s->s_user_ns);
> > kfree(s->s_subtype);
> > kfree(s->s_options);
> > kfree_rcu(s, rcu);
> > @@ -230,6 +231,8 @@ static struct super_block *alloc_super(struct
> file_system_type *type, int flags)
> > s->s_shrink.count_objects = super_cache_count;
> > s->s_shrink.batch = 1024;
> > s->s_shrink.flags = SHRINKER_NUMA_AWARE;
> > +
> > + s->s_user_ns = get_user_ns(&init_user_ns);
>
> Huh? I think I like this in principle, but shouldn't this be the
> actual userns doing the mount?
>
> > 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?
>
> --Andy
>

The xattr system calls go through xattr_permission before it ever gets to
the FUSE ops.

Regards,
Michael Theall

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/