Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754189AbdFMXuZ (ORCPT ); Tue, 13 Jun 2017 19:50:25 -0400 Received: from h2.hallyn.com ([78.46.35.8]:54752 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753825AbdFMXuV (ORCPT ); Tue, 13 Jun 2017 19:50:21 -0400 Date: Tue, 13 Jun 2017 18:50:25 -0500 From: "Serge E. Hallyn" To: "Serge E. Hallyn" Cc: Stefan Berger , "Eric W. Biederman" , Masami Ichikawa , containers@lists.linux-foundation.org, lkp@01.org, xiaolong.ye@intel.com, LKML , Mimi Zohar Subject: Re: [PATCH v4] Introduce v3 namespaced file capabilities Message-ID: <20170613235025.GB15685@mail.hallyn.com> References: <20170507092105.GA67584@inn.lkp.intel.com> <20170508044408.GA11400@mail.hallyn.com> <20170508181156.GA23112@mail.hallyn.com> <9f80188c-df03-066a-5dac-785cc711d064@linux.vnet.ibm.com> <20170613234214.GA15685@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170613234214.GA15685@mail.hallyn.com> 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 Content-Length: 2710 Lines: 64 Quoting Serge E. Hallyn (serge@hallyn.com): > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): > > On 05/08/2017 02:11 PM, Serge E. Hallyn wrote: > > >Root in a non-initial user ns cannot be trusted to write a traditional > > >security.capability xattr. If it were allowed to do so, then any > > >unprivileged user on the host could map his own uid to root in a private > > >namespace, write the xattr, and execute the file with privilege on the > > >host. > > > > > >However supporting file capabilities in a user namespace is very > > >desirable. Not doing so means that any programs designed to run with > > >limited privilege must continue to support other methods of gaining and > > >dropping privilege. For instance a program installer must detect > > >whether file capabilities can be assigned, and assign them if so but set > > >setuid-root otherwise. The program in turn must know how to drop > > >partial capabilities, and do so only if setuid-root. > > > > Hi Serge, > > > > > > I have been looking at patch below primarily to learn how we could > > apply a similar technique to security.ima and security.evm for a > > namespaced IMA. From the paragraphs above I thought that you solved > > the problem of a shared filesystem where one now can write different > > security.capability xattrs by effectively supporting for example > > security.capability[uid=1000] and security.capability[uid=2000] > > Interesting idea. Worth considering. > > > written into the filesystem. Each would then become visible as > > security.capability if the userns mapping is set appropriately. > > However, this doesn't seem to be how it is implemented. There seems > > Indeed, when I was considering supporting multiple simulatenous > xattrs, I did it as something like: > > struct vfs_ns_cap_data { > struct { > __le32 permitted; > __le32 inheritable; > } data[VFS_CAP_U32]; > __le32 rootid; > }; > > struct vfs_ns_cap { > __le32 magic_etc; > __le32 n_entries; > struct ns_cap_data data[0]; > }; // followed by n_entries of struct ns_cap_data > > You're instead suggesting encoding the rootuid in the name, > which is interesting. > > > to be only a single such entry with uid appended to it and, if it > > was a shared filesystem, the first one to set this attribute blocks > > everyone else from writing the xattr. Is that how it works? Would > > Approximately - indeed there is only a single xattr. But it can be > overwritten, so long as the writer has CAP_SETFCAP over the user_ns > which mounted the filesystem. Hang on. I've mis-spoken. That's the requirement for writing a v2 xattr. To write a v3 xattr you only need to be privileged (with CAP_SETFCAP) against the inode.