Message-ID: <20111219040604.GA2205@hallyn.com>
Date:	Mon, 19 Dec 2011 04:06:04 +0000
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Colin Walters <walters@...bum.org>,
	LKML <linux-kernel@...r.kernel.org>, alan@...rguk.ukuu.org.uk,
	morgan@...nel.org, luto@....edu, kzak@...hat.com,
	Steve Grubb <sgrubb@...hat.com>
Subject: Re: chroot(2) and bind mounts as non-root

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> Colin Walters <walters@...bum.org> writes:
> 
> > On Thu, 2011-12-15 at 22:14 -0800, Eric W. Biederman wrote:
> >
> >> Which means it is safe to enter a new user namespace without root
> >> privileges as once you are in if you execute a suid app it will be suid
> >> relative to your user namespace.  The careful changing of capable to
> >> ns_capable will allow other namespaces and other things that today are
> >> root only because of fears of mucking up the execution environment to be
> >> enabled.
> >> 
> >> What is slightly up in the air is how do we map user namespaces to
> >> filesystems.  The simplest solution looks to be to setup a uid and gid
> >> mappings from each child user namespace to the initial system user
> >> namespace.  Then in a child user namespace setuid(2) will fail if
> >> you attempt to use an id that does not have a mapping.
> >
> > But setting up a mapping is a privileged operation, right?  So then it
> > seems that practically speaking in an "out of the box" scenario on a
> > distro like RHEL or Debian, since there's no mapping configured, after a
> > process enters a new namespace it can't run setuid binaries?  
> 
> Sort of.  Allowing the use of more than your current uid in the mapping
> is a privileged operation.  I have a prototype that does an upcall using
> the request-key infrastructure for the validation.

If I understand you both right, I think what Eric said here is not relevant
to what Colin cares about.

Colin, for the case of "fakeroot debian/rules binary" or
build+create-tarball inside of a user namespace, all that will matter
to you is that yes, inside the user namespace which you created without
privilege you will be able to create files which are owned by (the user
namespace's) root, and so you'll be able to get the tarball or .deb with
root owned files.

The mapping Eric is talking about here is new even to me, but I think it
is an implementation detail referring to a proposal where each uid in the
container maps to a real uid on the host.  The only thing about that mapping
that matters is that none of the host uids conflict with existing host
uids (or uids mapped for other containers).  Now if you want to do cool
things like map uid 501 on the host to 1001 in the container as well as
502 on the host to 1010 in the container, that will be supported - and I
think that's what Eric is referring to.

But for the sake of fire-off-a-build, you can ignore that and use random
uids on the host side of the mapping.

> I expect by the time this makes it to "out of the box" experiences on
> enterprise distros, useradd and friends will be giving out 1000 or so uids
> to new accounts.
> 
> > Also I don't see how user namespaces can replace "fakeroot" if this is
> > true.  The whole point of fakeroot is being able to do things like "make
> > install DESTDIR=/home/user/tmpdir && tar cz -C /home/user/tmpdir -f
> > foo.tar.gz ." to get a tarball with root-owned files, without actually
> > requiring the privileges to temporarily make real root owned files.  But
> > without a privileged mapping operation there's no way to map uid 0 in
> > the namespace to something else on the filesystem, right?
> 
> Inside the user namespace the creators uid appears as uid 0.

That's the most important thing, for your (Colin) use case, which should
give you what you ened.

...

> > So it seems like practically speaking if the goal is to be able to
> > securely run code that "feels like" uid 0 in a container (e.g. start
> > apache) you have to drop off most of the capabilities that let you take
> > over the "host".  There's a number of these in CAP_SYS_ADMIN.
> 
> You misunderstood.  And you can look at the code in the kernel right
> now for how this is implemented.
> 
> CAP_SYS_ADMIN in a user namespace is not the global CAP_SYS_ADMIN.

In particular, compare

capable(CAP_SYS_ADMIN)

to

ns_capable(ns, CAP_SYS_ADMIN).

...

> I think the user namespace will do what you need. Certainly it appears

As do I.

> that everything in your example binary will be allowed by the time it is
> done.  Still there is the old saying about a bird in the hand being
> worth more than two birds in the bush.
> 
> Eric

Right, this isn't there yet, after all, and your (Colin) program is  :)

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

Powered by blists - more mailing lists