lkml.org 
[lkml]   [2014]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs only with a mount option
    Seth Forshee <seth.forshee@canonical.com> writes:

    > On Tue, Oct 14, 2014 at 01:01:02PM -0700, Eric W. Biederman wrote:
    >> Michael j Theall <mtheall@us.ibm.com> writes:
    >>
    >> > Seth Forshee <seth.forshee@canonical.com> wrote on 10/14/2014 09:25:55 AM:
    >> >
    >> >> From: Seth Forshee <seth.forshee@canonical.com>
    >> >> To: Miklos Szeredi <miklos@szeredi.hu>
    >> >> Cc: fuse-devel@lists.sourceforge.net, "Serge H. Hallyn"
    >> >> <serge.hallyn@ubuntu.com>, linux-kernel@vger.kernel.org, Seth
    >> >> Forshee <seth.forshee@canonical.com>, "Eric W. Biederman"
    >> >> <ebiederm@xmission.com>, linux-fsdevel@vger.kernel.org
    >> >> 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 extN filesystem
    with the right labels having it auto-mounted nosuid and subvert the
    security of something like selinux.

    > 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.

    Eric



    \
     
     \ /
      Last update: 2014-10-14 23:41    [W:4.064 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site