Date:	Fri, 14 Dec 2012 20:29:21 +0000
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	containers@...ts.linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	linux-security-module@...r.kernel.org
Subject: Re: [RFC][PATCH] Fix cap_capable to only allow owners in the
 parent user namespace to have caps.

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> "Serge E. Hallyn" <serge@...lyn.com> writes:

Note: I acked your patch before and still don't object to it.

> > In which case it would be
> >
> >        child_user_ns1  [100000-199999]
> >        child_user_ns2  [100000-199999]
> >          child_user_ns3  [120000-129999]
> >
> 
> Yes.  You have to nest uids.
> 
> >> > with unfortunate mappings  - ns1 and ns2 should have had nonoverlapping
> >> > ranges, but in any case now uid 1000 in ns1 can exert privilege over
> >> > ns3.  Again, uids comparisons will succeed for file access anyway, so
> >> > ns1 can 0wn ns2 and ns3 other ways.
> >> 
> >> Yes yours is the more realistic scenario.  Mine was simplified to be clear.
> >> 
> >> > Heck I'm starting to think the bug is a feature - surely given the
> >> > mappings above I meant for ns1 and ns2 to bleed privilege to each
> >> > other?
> >> 
> >> The serious problem is that privileges can bleed up. A user in 
> >> ns3 can wind up owning ns2 or ns1.  Which totally defeats the permission
> >> model.  You have CAP_DAC_OVERRIDE so you don't even need access to files
> >> you own, etc, etc.
> >
> > Would that not require intervention from the init_user_ns?  In my
> > example above (let's add that ns2 is owned by kuid.uid=1000 in
> > init_user_ns), root in child_user_ns2 cannot map kuid.val=0 or
> > kuid.val=1000 into ns3 because 0 and 1000 are not in the range
> > 100000-199999.  So there is no uid in child_user_ns3 which is able
> > to spoof uid=0 in child_user_ns1.
> 
> Right.  It does require having the uid of the owner of ns1 or ns2 in
> ns3.  So you have to explicitly allow it.
> 
> What I don't see is any point in allowing something like that.

The point isn't specifically to allow that, but rather to not muddle the
kuids with the user namespace *.

If I clone two tasks in separate user namespace but give them the same
uid mappings, how should the uids between those namespaces be related?
The way you're doing it now they will equate for DAC checks but not
for privilege checks.  It feels ad-hoc and flaky.

> A child user namespace having capabilities against processes in it's
> parent seems totally bizarre and pretty dangerous from a capabilities
> standpoint.

How would it have them against its parent?

> That said Serge I think I have lost track of the point of your question.

Look at it this way.  You've introduced kuids which allow "uids" to be
disassociated from the user namespace * in kernel.  You have the uid
mapping rules which enforce some sanity (requiring nesting).

If the parent ns has re-used an active uid of its own to give to a child
namespace, then any DAC-governed objects (files in particular) will be
owned by that uid in the child user ns.  I'm not sure - does this also
apply to /proc/$$/fd/* access?

-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