linux-kernel - Re: [CRIU] 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] [day] [month] [year] [list]

Message-ID: <20160713035926.GJ4916@odin.tremily.us>
Date:	Tue, 12 Jul 2016 20:59:26 -0700
From:	"W. Trevor King" <wking@...mily.us>
To:	Andrew Vagin <avagin@...tuozzo.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
	Linux API <linux-api@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>, criu@...nvz.org
Subject: Re: [CRIU] Introspecting userns relationships to other namespaces?

On Tue, Jul 12, 2016 at 05:08:43PM -0700, Andrew Vagin wrote:
> Here is a patch to get an owning user namespace:
> https://github.com/avagin/linux-task-diag/commit/7fad8ff3fc4110bebf0920cec2388390b3bd2238
> https://github.com/avagin/linux-task-diag/commit/2663bc803d324785e328261f3c07a0fef37d2088
>
> Here is an example how it looks from user-space:
> https://github.com/avagin/linux-task-diag/blob/namespaces/tools/testing/selftests/nsfs/owner.c#L49

Overall this looks good to me (I left a handful of uninformed comments
inline ;).

It doesn't make it easy to walk leafward, but it doesn't look like the
kernel has a convenient way to list child namespaces either.
Something like /proc/<pid>/task/<tid>/children (with
CONFIG_PROC_CHILDREN) for namespaces would make it easier to get a
complete system overview (as far as your credentials and position in
the namespace hierarchies allow).  But looking at the
CONFIG_PROC_CHILDREN implementation doesn't make me all that excited
about mimicking it for namespaces ;).

You can still brute-force it in userspace by walking the root-most
procfs's you can find and peeking at all the /proc/<pid>/ns/… entries
(but yuck ;).  With mount and other namespaces not being hierarchical,
the “leafword” idea may not be all that useful anyway, but having a
more compact collection of mount namepaces (say) that you know about
would be nice.  Where “know about” should probably means “know it
exists” but not necessarily “have permission to enter”.  Still,
getting that figured out can happen independently to this parent/owner
work.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)