Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932081AbeAHS4V (ORCPT + 1 other); Mon, 8 Jan 2018 13:56:21 -0500 Received: from mail-yw0-f172.google.com ([209.85.161.172]:44798 "EHLO mail-yw0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756104AbeAHS4S (ORCPT ); Mon, 8 Jan 2018 13:56:18 -0500 X-Google-Smtp-Source: ACJfBot0ublfhWZkLZlBZQhq7TWlTrPdW7cwzVozmjOpFn1nuTW9ohW/eauTUXMkWqmrY06fMmmInc7ixXyvrWo3gxE= MIME-Version: 1.0 In-Reply-To: <20180108183610.GA562@mail.hallyn.com> References: <20180108062452.GA21717@mail.hallyn.com> <20180108154733.GA29416@mail.hallyn.com> <20180108181121.GA32302@mail.hallyn.com> <20180108183610.GA562@mail.hallyn.com> From: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?= Date: Mon, 8 Jan 2018 10:55:56 -0800 Message-ID: Subject: Re: [PATCHv3 0/2] capability controlled user-namespaces To: "Serge E. Hallyn" Cc: James Morris , LKML , Netdev , Kernel-hardening , Linux API , Kees Cook , "Eric W . Biederman" , Eric Dumazet , David Miller , Mahesh Bandewar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Mon, Jan 8, 2018 at 10:36 AM, Serge E. Hallyn wrote: > Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com): >> On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn wrote: >> > Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com): >> >> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn wrote: >> >> > Quoting James Morris (james.l.morris@oracle.com): >> >> >> On Mon, 8 Jan 2018, Serge E. Hallyn wrote: >> >> >> I meant in terms of "marking" a user ns as "controlled" type -- it's >> >> >> unnecessary jargon from an end user point of view. >> >> > >> >> > Ah, yes, that was my point in >> >> > >> >> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/01845.html >> >> > and >> >> > http://lkml.iu.edu/hypermail/linux/kernel/1711.1/02276.html >> >> > >> >> >> This may happen internally but don't make it a special case with a >> >> >> different name and don't bother users with internal concepts: simply >> >> >> implement capability whitelists with the default having equivalent >> > >> > So the challenge is to have unprivileged users be contained, while >> > allowing trusted workloads in containers created by a root user to >> > bypass the restriction. >> > >> > Now, the current proposal actually doesn't support a root user starting >> > an application that it doesn't quite trust in such a way that it *is* >> > subject to the whitelist. >> >> Well, this is not hard since root process can spawn another process >> and loose privileges before creating user-ns to be controlled by the >> whitelist. > > It would have to drop cap_sys_admin for the container to be marked as > "controlled", which may prevent the container runtime from properly starting > the container. > Yes, but that's a conflict of trusted operations (that requires SYS_ADMIN) and untrusted processes it may spawn. >> You need an ability to preserve the creation of user-namespaces that >> exhibit 'the uncontrolled behavior' and only trusted/privileged (root) >> user should have it which is maintained here. >> >> > Which is unfortunate. But apart from using >> > ptags or a cgroup, I can't think of a good way to get us everything we >> > want: >> > >> > 1. unprivileged users always restricted >> > 2. existing unprivileged containers become restricted when whitelist >> > is enabled >> > 3. privileged users are able to create containers which are not restricted >> >> all this is achieved by the patch-set without any changes to the >> application with the above knob. >> >> > 4. privileged users are able to create containers which *are* restricted >> > >> With this patch-set; the root user process can fork another process >> with less privileges before creating a user-ns if the exec-ed process >> cannot be trusted. So there is a way with little modification as >> opposed to nothing available at this moment for this scenario.