From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751798AbdF1Fll (ORCPT ); Wed, 28 Jun 2017 01:41:41 -0400 Received: from h2.hallyn.com ([78.46.35.8]:33892 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750934AbdF1Fle (ORCPT ); Wed, 28 Jun 2017 01:41:34 -0400 Date: Wed, 28 Jun 2017 00:41:38 -0500 From: "Serge E. Hallyn" To: Amir Goldstein Cc: Stefan Berger , "Eric W. Biederman" , Linux Containers , lkp@01.org, xiaolong.ye@intel.com, linux-kernel , Mimi Zohar , "Serge E. Hallyn" , Tycho Andersen , James Bottomley , christian.brauner@mailbox.org, Vivek Goyal , LSM List Subject: Re: [PATCH 0/3] Enable namespaced file capabilities Message-ID: <20170628054138.GA15939@mail.hallyn.com> References: <1498157989-11814-1-git-send-email-stefanb@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 23, 2017 at 10:01:46AM +0300, Amir Goldstein wrote: > On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger > wrote: > > This series of patches primary goal is to enable file capabilities > > in user namespaces without affecting the file capabilities that are > > effective on the host. This is to prevent that any unprivileged user > > on the host maps his own uid to root in a private namespace, writes > > the xattr, and executes the file with privilege on the host. > > > > We achieve this goal by writing extended attributes with a different > > name when a user namespace is used. If for example the root user > > in a user namespace writes the security.capability xattr, the name > > of the xattr that is actually written is encoded as > > security.capability@uid=1000 for root mapped to uid 1000 on the host. > > When listing the xattrs on the host, the existing security.capability > > as well as the security.capability@uid=1000 will be shown. Inside the > > namespace only 'security.capability', with the value of > > security.capability@uid=1000, is visible. > > > > Am I the only one who thinks that suffix is perhaps not the best grammar > to use for this namespace? > xattrs are clearly namespaced by prefix, so it seems right to me to keep > it that way - define a new special xattr namespace "ns" and only if that > prefix exists, the @uid suffix will be parsed. > This could be either ns.security.capability@uid=1000 or > ns@uid=1000.security.capability. The latter seems more correct to me, > because then we will be able to namespace any xattr without having to > protect from "unprivileged xattr injection", i.e.: > setfattr -n "user.whatever.foo@uid=0" > > Amir. Hi Amir, I was liking the prefix at first, but I'm actually not sure it's worth it. THe main advantage would be so that checking for namespace or other tags could be done always at the same offset simplifying the parser. But since we will want to only handle namespacing for some tags, and potentially differently for each task, it won't actually be simpler, I don't think. On the other hand we do want to make sure that the syntax we use is generally usable, so I think simply specifying that >1 tags can each be separate by '@' should suffice. So for now we'd only have security.capability@uid=100000 soon we'd hopefully have security.ima@uid=100000 and eventually trusted.blarb@foo=bar -serge