From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754625AbdFWSJM (ORCPT ); Fri, 23 Jun 2017 14:09:12 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:33845 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754068AbdFWSJL (ORCPT ); Fri, 23 Jun 2017 14:09:11 -0400 Subject: Re: [PATCH 0/3] Enable namespaced file capabilities To: Casey Schaufler , "Serge E. Hallyn" , Amir Goldstein References: <1498157989-11814-1-git-send-email-stefanb@linux.vnet.ibm.com> <20170623160026.GA18257@mail.hallyn.com> Cc: "Eric W. Biederman" , Linux Containers , lkp@01.org, xiaolong.ye@intel.com, linux-kernel , Mimi Zohar , Tycho Andersen , James Bottomley , christian.brauner@mailbox.org, Vivek Goyal , LSM List From: Stefan Berger Date: Fri, 23 Jun 2017 14:08:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17062318-0012-0000-0000-000014861C2A X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007279; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00878855; UDB=6.00437960; IPR=6.00659006; BA=6.00005438; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015944; XFM=3.00000015; UTC=2017-06-23 18:08:58 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17062318-0013-0000-0000-00004E469189 Message-Id: <3404c486-c848-3283-50f7-2283cb631e8e@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-23_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230303 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/23/2017 12:16 PM, Casey Schaufler wrote: > On 6/23/2017 9:00 AM, Serge E. Hallyn wrote: >> Quoting Amir Goldstein (amir73il@gmail.com): >>> 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? >> You're the only one to have mentioned it so far. >> >>> 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" >> I like it for simplifying the parser code. One concern I have is that, >> since ns.* is currently not gated, one could write ns.* on an older >> kernel and then exploit it on a newer one. > security.ns.capability@uid=1000, then? Imo, '.ns' is redundant and 'encoded' in the '@'. Stefan