From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vivek Goyal Subject: Re: [PATCH 0/3] Enable namespaced file capabilities Date: Fri, 23 Jun 2017 16:09:56 -0400 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-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1498157989-11814-1-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Stefan Berger Cc: lkp-JC7UmRfGjtg@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, xiaolong.ye-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org List-Id: containers.vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: vgoyal@redhat.com (Vivek Goyal) Date: Fri, 23 Jun 2017 16:09:56 -0400 Subject: [PATCH 0/3] Enable namespaced file capabilities In-Reply-To: <1498157989-11814-1-git-send-email-stefanb@linux.vnet.ibm.com> References: <1498157989-11814-1-git-send-email-stefanb@linux.vnet.ibm.com> Message-ID: <20170623200956.GB24779@redhat.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org 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 at 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 at uid=1000 will be shown. Inside the > namespace only 'security.capability', with the value of > security.capability at uid=1000, is visible. Hi Stefan, Got a question. If child usernamespace sets a security.capability at 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 at uid=1000 xattr: security.selinux # outside user namespace setfattr -x security.capability at uid foo.txt setfattr: foo.txt: Invalid argument Doing a strace shows removexattr() failed. May this will need fixing? removexattr("testfile.txt", "security.capability at uid") = -1 EINVAL (Invalid argument) Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5965268362138147769==" MIME-Version: 1.0 From: Vivek Goyal To: lkp@lists.01.org Subject: Re: [PATCH 0/3] Enable namespaced file capabilities Date: Fri, 23 Jun 2017 16:09:56 -0400 Message-ID: <20170623200956.GB24779@redhat.com> In-Reply-To: <1498157989-11814-1-git-send-email-stefanb@linux.vnet.ibm.com> List-Id: --===============5965268362138147769== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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(a)uid=3D1000 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(a)uid=3D1000 will be shown. Inside the > namespace only 'security.capability', with the value of > security.capability(a)uid=3D1000, is visible. Hi Stefan, Got a question. If child usernamespace sets a security.capability(a)uid=3D1000, 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(a)uid=3D1000 xattr: security.selinux # outside user namespace setfattr -x security.capability(a)uid foo.txt setfattr: foo.txt: Invalid argument Doing a strace shows removexattr() failed. May this will need fixing? removexattr("testfile.txt", "security.capability(a)uid") =3D -1 EINVAL (Invalid argument) Vivek --===============5965268362138147769==-- From mboxrd@z Thu Jan 1 00:00:00 1970 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 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