From: ebiederm@xmission.com (Eric W. Biederman)
To: Michael j Theall <mtheall@us.ibm.com>
Cc: fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
        "Serge H. Hallyn" <serge.hallyn@ubuntu.com>,
        Andy Lutomirski <luto@amacapital.net>
References: <1413296756-25071-1-git-send-email-seth.forshee@canonical.com>
	<1413296756-25071-5-git-send-email-seth.forshee@canonical.com>
	<OFD40DA8DF.F78EA39D-ON86257D71.0057C4DC-86257D71.0064055D@us.ibm.com>
	<878ukis9oh.fsf@x220.int.ebiederm.org>
	<20141014205955.GA10908@ubuntu-mba51>
Date: Tue, 14 Oct 2014 14:13:08 -0700
In-Reply-To: <20141014205955.GA10908@ubuntu-mba51> (Seth Forshee's message of
	"Tue, 14 Oct 2014 22:59:55 +0200")
Message-ID: <877g02pd7f.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs only with a mount option
Sender: linux-kernel-owner@vger.kernel.org

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

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