linux-kernel - Re: [PATCH 3/3] fuse: Allow mounts from user namespaces

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <20140721124725.GB111224@ubuntu-hedt>
Date:	Mon, 21 Jul 2014 07:47:25 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	fuse-devel <fuse-devel@...ts.sourceforge.net>,
	lxc-devel@...ts.linuxcontainers.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	"Michael H. Warfield" <mhw@...tsend.com>
Subject: Re: [PATCH 3/3] fuse: Allow mounts from user namespaces

On Fri, Jul 18, 2014 at 05:33:23PM +0200, Miklos Szeredi wrote:
> On Mon, Jul 14, 2014 at 9:18 PM, Seth Forshee
> <seth.forshee@...onical.com> wrote:
> > Update fuse to allow mounts from user namespaces. During mount
> > current_user_ns() is stashed away,
> 
> Same thing here.  While practically this may work, it's theoretically
> wrong, and possibly may go wrong in special situations.   In fuse
> there's no official "server process", so storing information, like
> namespace, about one is going to be wrong.

What you're suggesting would probably work fine when dealing with pids.
It's not going to work though for the checks I've added in
fuse_allow_current_process() that the process is in the mount owner's
user ns, and without those checks or something similar I don't think
it's safe to permit allow_other for user ns mounts.

I realize that "server process" isn't perfect terminology, it was just
the shorthand I came up with for "the process reading/writing on
/dev/fuse for this super block," which I assumed would be a single
process and certainly not multiple processes in different namespaces.
Can you elaborate on what special situations might violate these
assumptions or otherwise cause problems?

Maybe an alternative approach for the user namspace would be to use the
one which owns the mount namespace of the mount. I'm just not sure off
the top of my head whether or not there's a way for fuse to get to that
information.

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