Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755061AbdFWUKD (ORCPT ); Fri, 23 Jun 2017 16:10:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48050 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755040AbdFWUJ7 (ORCPT ); Fri, 23 Jun 2017 16:09:59 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C40DC19D05F Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=vgoyal@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C40DC19D05F Date: Fri, 23 Jun 2017 16:09:56 -0400 From: Vivek Goyal To: Stefan Berger Cc: ebiederm@xmission.com, containers@lists.linux-foundation.org, lkp@01.org, xiaolong.ye@intel.com, linux-kernel@vger.kernel.org, zohar@linux.vnet.ibm.com, serge@hallyn.com, tycho@docker.com, James.Bottomley@HansenPartnership.com, christian.brauner@mailbox.org, amir73il@gmail.com, linux-security-module@vger.kernel.org Subject: Re: [PATCH 0/3] Enable namespaced file capabilities Message-ID: <20170623200956.GB24779@redhat.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: <1498157989-11814-1-git-send-email-stefanb@linux.vnet.ibm.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 23 Jun 2017 20:09:58 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1662 Lines: 43 On Thu, Jun 22, 2017 at 02:59:46PM -0400, 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. Hi Stefan, Got a question. If child usernamespace sets a security.capability@uid=1000, can any of the parent namespace remove it? IOW, I set capability from usernamespace and tried to remove it from host and that failed. Is that expected. # Inside usernamespce $setcap cat_net_raw+ep foo.txt # outside user namespace $listxattr foo.txt xattr: security.capability@uid=1000 xattr: security.selinux # outside user namespace setfattr -x security.capability@uid foo.txt setfattr: foo.txt: Invalid argument Doing a strace shows removexattr() failed. May this will need fixing? removexattr("testfile.txt", "security.capability@uid") = -1 EINVAL (Invalid argument) Vivek