Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754586AbdFWRHj (ORCPT ); Fri, 23 Jun 2017 13:07:39 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:40704 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753926AbdFWRHi (ORCPT ); Fri, 23 Jun 2017 13:07:38 -0400 Message-ID: <1498237641.3641.15.camel@HansenPartnership.com> Subject: Re: [PATCH 0/3] Enable namespaced file capabilities From: James Bottomley To: "Serge E. Hallyn" , Casey Schaufler Cc: Amir Goldstein , Stefan Berger , "Eric W. Biederman" , Linux Containers , lkp@01.org, xiaolong.ye@intel.com, linux-kernel , Mimi Zohar , Tycho Andersen , christian.brauner@mailbox.org, Vivek Goyal , LSM List Date: Fri, 23 Jun 2017 10:07:21 -0700 In-Reply-To: <20170623163030.GA18820@mail.hallyn.com> References: <1498157989-11814-1-git-send-email-stefanb@linux.vnet.ibm.com> <20170623160026.GA18257@mail.hallyn.com> <20170623163030.GA18820@mail.hallyn.com> 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 Content-Length: 1573 Lines: 35 On Fri, 2017-06-23 at 11:30 -0500, Serge E. Hallyn wrote: > Quoting Casey Schaufler (casey@schaufler-ca.com): > > Or maybe just security.ns.capability, taking James' comment into > > account. > > That last one may be suitable as an option, useful for his particular > (somewhat barbaric :) use case, but it's not ok for the general > solution. > > If uid 1000 was delegated the subuids 100000-199999, it should be > able to write a file capability for use by his subuids, but that file > capability must not apply to other subuids. I don't think it's barbaric, I think it's the common use case. Let me give a more comprehensible answer in terms of docker and IMA. Lets suppose I'm running docker locally and in a test cloud both with userns enabled. I build an image locally, mapping my uid (1000) to root. If I begin with a standard base, each of the files has a security.ima signature. Now I add my layer, which involves updating a file, so I need to write a new signature to security.ima. Because I'm running user namespaced, the update gets written at security.ima@uid=1000 when I do a docker save. Now supposing I deploy that image to a cloud. As a tenant, the cloud gives me real uid 4531 and maps that to root. Execution of the binary fails because it tries to use the underlying signature (in security.ima) as there is no xattr named security.ima@uid=4531 So my essential point is that building the real kuid into the permanent record of the xattr damages image portability, which is touted as one of the real advantages of container images. James