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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 08 Jul 2016 18:52:09 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	Andrew Vagin <avagin@...tuozzo.com>,
	Linux API <linux-api@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>, criu@...nvz.org,
	"Michael Kerrisk \(man-pages\)" <mtk.manpages@...il.com>
Subject: Re: [CRIU] Introspecting userns relationships to other namespaces?

James Bottomley <James.Bottomley@...senpartnership.com> writes:

> On July 8, 2016 1:38:19 PM PDT, Andrew Vagin <avagin@...tuozzo.com> wrote:

>>What do you think about the idea to mount nsfs and be able to look up
>>any alive namespace by inum:
>
> I think I like it.  It will give us a way to enter any extant
> namespace.  It will work for Eric's fs namespaces as well.  Perhaps a
> /process/ns/<inum> Directory?

*Shivers*

That makes it very easy to bypass any existing controls that exist for
getting at namespaces.  It is true that everything of that kind is
directory based but still.

Plus I think it would serve as information leak to information outside
of the container.

An operation to get a user namespace file descriptor from some kernel
object sounds reasonably sane.

A great big list of things sounds about as scary as it can get.  This is
not the time to be making it easier to escape from containers.

Eric