linux-kernel - Re: Introspecting userns relationships to other 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]

Date:	Thu, 7 Jul 2016 13:24:42 -0500
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Linux API <linux-api@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>, criu@...nvz.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: Introspecting userns relationships to other namespaces?

Quoting Michael Kerrisk (man-pages) (mtk.manpages@...il.com):
> On 7 July 2016 at 17:01, James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
> > On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
> >> Quoting Michael Kerrisk (man-pages) (mtk.manpages@...il.com):
> >> > Hi Serge,
> >> >
> >> > On 6 July 2016 at 16:13, Serge E. Hallyn <serge@...lyn.com> wrote:
> >> > > On Wed, Jul 06, 2016 at 10:41:48AM +0200, Michael Kerrisk (man
> >> > > -pages) wrote:
> >> > > > [Rats! Doing now what I should have down to start with. Looping
> >> > > > some lists and CRIU and other possibly relevant people into
> >> > > > this conversation]
> >> > > >
> >> > > > Hi Eric,
> >> > > >
> >> > > > On 5 July 2016 at 23:47, Eric W. Biederman <
> >> > > > ebiederm@...ssion.com> wrote:
> >> > > > > "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
> >> > > > > writes:
> >> > > > >
> >> > > > > > Hi Eric,
> >> > > > > >
> >> > > > > > I have a question. Is there any way currently to discover
> >> > > > > > which user namespace a particular nonuser namespace is
> >> > > > > > governed by? Maybe I am missing something, but there does
> >> > > > > > not seem to be a way to do this. Also, can one discover
> >> > > > > > which userns is the parent of a given userns? Again, I
> >> > > > > > can't see a way to do this.
> >> > > > > >
> >> > > > > > The point here is introspecting so that a process might
> >> > > > > > determine what its capabilities are when operating on some
> >> > > > > > resource governed by a (nonuser) namespace.
> >> > > > >
> >> > > > > To the best of my knowledge that there is not an interface to
> >> > > > > get that information.  It would be good to have such an
> >> > > > > interface for no other reason than the CRIU folks are going
> >> > > > > to need it at some point.  I am a bit surprised they have not
> >> > > > > complained yet.
> >> > >
> >> > > I don't think they need it.  They do in fact have what they need.
> >> > >   Assume you have tasks T1, T2, T1_1 and T2_1;  T1 and T2 are in
> >> > > init_user_ns;  T1 spawned T1_1 in a new userns;  T2 spawned T2_1
> >> > > which setns()d to T1_1's ns. There's some {handwave} uid mapping,
> >> > > does not matter.
> >> > >
> >> > > At restart, it doesn't matter which task originally created the
> >> > > new userns. criu knows T1_1 and T2_1 are in the same userns;  it
> >> > > creates the userns, sets up the mapping, and T1_1 and T2_1
> >> > > setns() to it.
> >> >
> >> > I'm missing something here. How does the parental relationships
> >> > between the user namespaces get reconstructed? Those relationships
> >> > will govern what capabilities a process will have in various user
> >> > namespaces.
> >
> > Actually, you get the parent namespace from the process tree by
> > tracking the user namespaces of the parent pids.   Currently non-root
> > users can't bind the namespace, so the only way to keep a new user_ns
> > around if you're not root is to keep the process around, so for
> > multiply nested user namespaces you can usually build the user_ns
> > hierarchy by looking at the process hierarchy.  Conversely, if the
> > process is reparented to init, chances are that the user_ns is also
> > parented to init_user_ns.
> 
> Yes, but "chances are" == this isn't robust.  PR_SET_CHILD_SUBREAPER
> further complicates things.
> 
> By the way, is that really what happens? Do child user namespaces get
> reparented to the grandparent ns if the parent ns disappears (i.e.,

The parent ns cannot disappear.  The child ns pins the creator's cred,
which pins the parent user_ns.