linux-kernel - Re: [PATCH v5 2/4] fuse: Support fuse filesystems outside of init_user

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Nov 2014 15:09:11 +0100
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	Seth Forshee <seth.forshee@...onical.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Serge H. Hallyn" <serge.hallyn@...ntu.com>,
	Andy Lutomirski <luto@...capital.net>,
	Michael j Theall <mtheall@...ibm.com>,
	fuse-devel <fuse-devel@...ts.sourceforge.net>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v5 2/4] fuse: Support fuse filesystems outside of
 init_user_ns

Quoting Miklos Szeredi (miklos@...redi.hu):
> On Wed, Nov 19, 2014 at 9:50 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
> > On Tue, Nov 18, 2014 at 4:21 PM, Seth Forshee
> > <seth.forshee@...onical.com> wrote:
> >>> I asked around a bit, and it turns out there are use cases for nested
> >> containers (i.e. a container within a container) where the rootfs for
> >> the outer container mounts a filesystem containing the rootfs for the
> >> inner container. If that mount is nosuid then suid utilities like ping
> >> aren't going to work in the inner container.
> >>
> >> So since there's a use case for suid in a userns mount and we have what
> >> we belive are sufficient protections against using this as a vector to
> >> get privileges outside the container, I'm planning to move ahead without
> >> the MNT_NOSUID restriction. Any objections?
> >
> > In the general case how'd we prevent suid executable being tricked to
> > do something it shouldn't do by unprivileged mounting into sensitive
> > places (i.e. config files) inside the container?

The design of the namespaces would prevent that.  You cannot manipulate your
mounts namespace unless you own it.  You cannot manipulate the mounts namespace
for a task whose user namespace you do not own.  If you can, for instance,
bind mount $HOME/shadow onto /etc/shadow, then you already own your user
namespace and are root there, so any suid-root program which you mount through
fuse will only subjegate your own namespace.  Any task which running in the
parent user-ns (and therefore parent mount-ns) will not see your bind mount.

> > Allowing SUID looks like a slippery slope to me.  And there are plenty
> > of solutions to the "ping" problem, AFAICS, that don't involve the
> > suid bit.
> 
> ping isn't even suid on my system, it has security.capability xattr instead.

security.capability xattrs that will have the exact same concerns wrt
confusion through bind mounts as suid.

> Please just get rid of SUID/SGID.  It's a legacy, it's a hack, not
> worth the complexity and potential problems arising from that
> complexity.

Oh boy, I don't know which side to sit on here :)  I'm all for replacing
suid with some use of file capabilities, but realistically there are reasons
why that hasn't happened more widely than it has - tar, package managers,
cpio, nfs, etc.

-serge
--
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/