lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 14 Oct 2014 14:29:13 -0700
From: (Eric W. Biederman)
To:	Andy Lutomirski <>
Cc:	Michael j Theall <>,,
	Linux FS Devel <>,
	"linux-kernel\" <>,
	Miklos Szeredi <>,
	"Serge H. Hallyn" <>
Subject: Re: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs only with a mount option

Andy Lutomirski <> writes:

> On Tue, Oct 14, 2014 at 2:13 PM, Eric W. Biederman
> <> wrote:
>> Seth Forshee <> writes:
>>> On Tue, Oct 14, 2014 at 01:01:02PM -0700, Eric W. Biederman wrote:
>>>> Michael j Theall <> writes:
>>>> > Seth Forshee <> wrote on 10/14/2014 09:25:55 AM:
>>>> >
>>>> >> From: Seth Forshee <>
>>>> >> To: Miklos Szeredi <>
>>>> >> Cc:, "Serge H. Hallyn"
>>>> >> <>,, Seth
>>>> >> Forshee <>, "Eric W. Biederman"
>>>> >> <>,
>>>> >> 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.
> 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.

Fair enough.  Smack does not replicate any form of that check so smack
appears vulnerable to untrusted media.

I don't think we have any other security modules beyond smack and
selinux that use labels.

>>> 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.
> Serge had also mentioned adding some kind of hook to help LSMs handle
> user namespaces more intelligently.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists