From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932875AbcGIAPi (ORCPT ); Fri, 8 Jul 2016 20:15:38 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:56864 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756297AbcGIAPf (ORCPT ); Fri, 8 Jul 2016 20:15:35 -0400 Message-ID: <1468023332.2390.10.camel@HansenPartnership.com> Subject: Re: [CRIU] Introspecting userns relationships to other namespaces? From: James Bottomley To: "Eric W. Biederman" Cc: Andrew Vagin , Linux API , Containers , lkml , criu@openvz.org, "Michael Kerrisk (man-pages)" Date: Fri, 08 Jul 2016 17:15:32 -0700 In-Reply-To: <87wpkvpu1i.fsf@x220.int.ebiederm.org> References: <87r3b7pxja.fsf@x220.int.ebiederm.org> <20160706141348.GB20728@mail.hallyn.com> <871t36kbvq.fsf@x220.int.ebiederm.org> <20160708015758.GA10512@outlook.office365.com> <87vb0gy3nr.fsf@x220.int.ebiederm.org> <1467988533.2322.118.camel@HansenPartnership.com> <20160708203818.GA2602@outlook.office365.com> <5e4cc802-f0e0-4f4c-a2f7-585aaaa8feec@email.android.com> <87wpkvpu1i.fsf@x220.int.ebiederm.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2016-07-08 at 18:52 -0500, Eric W. Biederman wrote: > James Bottomley writes: > > > On July 8, 2016 1:38:19 PM PDT, Andrew Vagin > > 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/ Directory? As you understood, I meant /proc/ns/ (damn mobile phone completions). > *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. To be honest, I think this argument is rubbish. If we're afraid of giving out a list of all the namespaces, it means we're afraid there's some security bug and we're trying to obscure it by making the list hard to get. All we've done is allayed fears about the bug but the hackers still know the portals to get through. If such a bug exists, it will be possible to exploit it by simply reconstructing the information from the individual process directories, so obscurity doesn't protect us and all it does is give us a false sense of security. If such a bug doesn't exist, then all the security mechanisms currently in place (like no re-entry to prior namespace) should protect us and we can give out the list. Let's deal with the world as we'd like it to be (no obscure namespace bugs) and accept the consequences and the responsibility for fixing them if we turn out to be slightly incorrect. We'll end up in a far better place than security by obscurity would land us. James