All of lore.kernel.org
 help / color / mirror / Atom feed
From: James.Bottomley@HansenPartnership.com (James Bottomley)
To: linux-security-module@vger.kernel.org
Subject: [PATCH 0/3] Enable namespaced file capabilities
Date: Thu, 22 Jun 2017 16:29:21 -0700	[thread overview]
Message-ID: <1498174161.7636.4.camel@HansenPartnership.com> (raw)
In-Reply-To: <1498157989-11814-1-git-send-email-stefanb@linux.vnet.ibm.com>

On Thu, 2017-06-22 at 14:59 -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.

I'm a bit bothered by the @uid=1000 suffix.  What if I want to use this
capability but am dynamically mapping the namespaces (i.e. I know I
want unprivileged root, but I'm going to dynamically select the range
to map based on what's currently available on the orchestration
system).  If we stick with the @uid=X suffix, then dynamic mapping
won't work because X is potentially different each time and there'll be
a name mismatch in my xattrs.  Why not just make the suffix @uid, which
means if root is mapped to any unprivileged uid then we pick this up
otherwise we go with the unsuffixed property?

As far as I can see there's no real advantage to discriminating userns
specific xattrs based on where root is mapped to, unless there's a use
case I'm missing?

James


--
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

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: lkp@lists.01.org
Subject: Re: [PATCH 0/3] Enable namespaced file capabilities
Date: Thu, 22 Jun 2017 16:29:21 -0700	[thread overview]
Message-ID: <1498174161.7636.4.camel@HansenPartnership.com> (raw)
In-Reply-To: <1498157989-11814-1-git-send-email-stefanb@linux.vnet.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

On Thu, 2017-06-22 at 14:59 -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=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(a)uid=1000 will be shown. Inside the
> namespace only 'security.capability', with the value of
> security.capability(a)uid=1000, is visible.

I'm a bit bothered by the @uid=1000 suffix.  What if I want to use this
capability but am dynamically mapping the namespaces (i.e. I know I
want unprivileged root, but I'm going to dynamically select the range
to map based on what's currently available on the orchestration
system).  If we stick with the @uid=X suffix, then dynamic mapping
won't work because X is potentially different each time and there'll be
a name mismatch in my xattrs.  Why not just make the suffix @uid, which
means if root is mapped to any unprivileged uid then we pick this up
otherwise we go with the unsuffixed property?

As far as I can see there's no real advantage to discriminating userns
specific xattrs based on where root is mapped to, unless there's a use
case I'm missing?

James



WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Stefan Berger <stefanb@linux.vnet.ibm.com>,
	ebiederm@xmission.com, containers@lists.linux-foundation.org
Cc: lkp@01.org, xiaolong.ye@intel.com, linux-kernel@vger.kernel.org,
	zohar@linux.vnet.ibm.com, serge@hallyn.com, tycho@docker.com,
	christian.brauner@mailbox.org, vgoyal@redhat.com,
	amir73il@gmail.com, linux-security-module@vger.kernel.org
Subject: Re: [PATCH 0/3] Enable namespaced file capabilities
Date: Thu, 22 Jun 2017 16:29:21 -0700	[thread overview]
Message-ID: <1498174161.7636.4.camel@HansenPartnership.com> (raw)
In-Reply-To: <1498157989-11814-1-git-send-email-stefanb@linux.vnet.ibm.com>

On Thu, 2017-06-22 at 14:59 -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.

I'm a bit bothered by the @uid=1000 suffix.  What if I want to use this
capability but am dynamically mapping the namespaces (i.e. I know I
want unprivileged root, but I'm going to dynamically select the range
to map based on what's currently available on the orchestration
system).  If we stick with the @uid=X suffix, then dynamic mapping
won't work because X is potentially different each time and there'll be
a name mismatch in my xattrs.  Why not just make the suffix @uid, which
means if root is mapped to any unprivileged uid then we pick this up
otherwise we go with the unsuffixed property?

As far as I can see there's no real advantage to discriminating userns
specific xattrs based on where root is mapped to, unless there's a use
case I'm missing?

James

  parent reply	other threads:[~2017-06-22 23:29 UTC|newest]

Thread overview: 180+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-22 18:59 [PATCH 0/3] Enable namespaced file capabilities Stefan Berger
2017-06-22 18:59 ` Stefan Berger
2017-06-22 18:59 ` Stefan Berger
2017-06-22 18:59 ` [PATCH 1/3] xattr: Enable security.capability in user namespaces Stefan Berger
2017-06-22 18:59   ` Stefan Berger
2017-06-22 18:59   ` Stefan Berger
2017-06-24 21:02   ` kbuild test robot
2017-06-24 21:02     ` kbuild test robot
2017-06-24 21:02     ` kbuild test robot
2017-06-24 21:02   ` [PATCH] xattr: fix kstrdup.cocci warnings kbuild test robot
2017-06-24 21:02     ` kbuild test robot
2017-06-24 21:02     ` kbuild test robot
     [not found]   ` <1498157989-11814-2-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-24 21:02     ` [PATCH 1/3] xattr: Enable security.capability in user namespaces kbuild test robot
2017-06-24 21:02     ` [PATCH] xattr: fix kstrdup.cocci warnings kbuild test robot
     [not found] ` <1498157989-11814-1-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-22 18:59   ` [PATCH 1/3] xattr: Enable security.capability in user namespaces Stefan Berger
2017-06-22 18:59   ` [PATCH 2/3] Enable capabilities of files from shared filesystem Stefan Berger
2017-06-22 18:59     ` Stefan Berger
2017-06-22 18:59     ` Stefan Berger
2017-06-22 18:59     ` Stefan Berger
2017-06-22 18:59   ` [PATCH 3/3] Enable security.selinux in user namespaces Stefan Berger
2017-06-22 19:59   ` [PATCH 0/3] Enable namespaced file capabilities Casey Schaufler
2017-06-22 23:29   ` James Bottomley
2017-06-23  7:01   ` Amir Goldstein
2017-06-23  7:01     ` Amir Goldstein
2017-06-23  7:01     ` Amir Goldstein
2017-06-23 16:00     ` Serge E. Hallyn
2017-06-23 16:00     ` Serge E. Hallyn
2017-06-23 16:00       ` Serge E. Hallyn
     [not found]       ` <20170623160026.GA18257-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 16:16         ` Casey Schaufler
2017-06-23 16:16           ` Casey Schaufler
2017-06-23 16:16           ` Casey Schaufler
2017-06-23 16:16           ` Casey Schaufler
2017-06-23 16:30           ` Serge E. Hallyn
2017-06-23 16:30             ` Serge E. Hallyn
2017-06-23 16:53             ` Casey Schaufler
2017-06-23 16:53               ` Casey Schaufler
2017-06-23 16:53               ` Casey Schaufler
2017-06-23 17:01               ` Serge E. Hallyn
2017-06-23 17:01                 ` Serge E. Hallyn
     [not found]                 ` <20170623170108.GA19354-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 17:49                   ` Eric W. Biederman
2017-06-23 17:49                 ` Eric W. Biederman
2017-06-23 17:49                   ` Eric W. Biederman
2017-06-23 17:49                   ` Eric W. Biederman
2017-06-23 18:32                   ` Serge E. Hallyn
2017-06-23 18:32                     ` Serge E. Hallyn
     [not found]                   ` <8760fmh9vc.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-06-23 18:32                     ` Serge E. Hallyn
     [not found]               ` <ef37880d-6baa-12a6-eab1-bcd0a4e94d53-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-23 17:01                 ` Serge E. Hallyn
     [not found]             ` <20170623163030.GA18820-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 16:53               ` Casey Schaufler
2017-06-23 17:07               ` James Bottomley
2017-06-23 17:07             ` James Bottomley
2017-06-23 17:07               ` James Bottomley
2017-06-23 17:07               ` James Bottomley
2017-06-23 17:38               ` Stefan Berger
2017-06-23 17:38                 ` Stefan Berger
2017-06-23 17:38                 ` Stefan Berger
2017-06-23 18:34                 ` Serge E. Hallyn
2017-06-23 18:34                   ` Serge E. Hallyn
     [not found]                 ` <d288ea69-adec-f257-30cb-b1d9c57c996b-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-23 18:34                   ` Serge E. Hallyn
     [not found]               ` <1498237641.3641.15.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-06-23 17:18                 ` Aleksa Sarai
     [not found]                   ` <b57803da-0e8b-594d-901b-12eb509f04b5-l3A5Bk7waGM@public.gmane.org>
2017-06-23 18:22                     ` Serge E. Hallyn
2017-06-23 17:20                 ` Serge E. Hallyn
2017-06-23 17:20                   ` Serge E. Hallyn
2017-06-23 17:20                   ` Serge E. Hallyn
     [not found]                   ` <20170623172016.GA19551-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 17:28                     ` Aleksa Sarai
     [not found]                       ` <553a72c4-eda9-52d6-2ae2-f8687c0c7c70-l3A5Bk7waGM@public.gmane.org>
2017-06-23 18:30                         ` Serge E. Hallyn
2017-06-25 12:35                         ` Eric W. Biederman
     [not found]                           ` <87lgogdz2t.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-06-25 13:06                             ` Aleksa Sarai
     [not found]                               ` <f1716e8c-dba8-a051-6bc7-285f13ffcaf0-l3A5Bk7waGM@public.gmane.org>
2017-06-25 13:28                                 ` Eric W. Biederman
     [not found]                                   ` <87zicwb3hu.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-06-25 13:51                                     ` Aleksa Sarai
     [not found]                                       ` <5bef361a-bc31-f3bc-f513-e728a48f0524-l3A5Bk7waGM@public.gmane.org>
2017-06-25 16:45                                         ` Serge E. Hallyn
     [not found]                                           ` <20170625164558.GA24471-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-26  6:14                                             ` Aleksa Sarai
2017-06-23 17:38                 ` Stefan Berger
     [not found]           ` <aa62373e-7cd6-39dd-2e38-2b6d6dbe18a8-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-23 16:30             ` Serge E. Hallyn
2017-06-23 18:08             ` Stefan Berger
2017-06-23 18:08           ` Stefan Berger
2017-06-23 18:08             ` Stefan Berger
2017-06-23 18:08             ` Stefan Berger
2017-06-23 18:35             ` Serge E. Hallyn
2017-06-23 18:35               ` Serge E. Hallyn
     [not found]               ` <20170623183520.GC21137-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 20:30                 ` Casey Schaufler
2017-06-23 20:30                   ` Casey Schaufler
2017-06-23 20:30                   ` Casey Schaufler
2017-06-23 20:30                   ` Casey Schaufler
2017-06-23 23:09                 ` Stefan Berger
2017-06-23 23:09                   ` Stefan Berger
2017-06-23 23:09                   ` Stefan Berger
2017-06-23 23:09                   ` Stefan Berger
     [not found]                   ` <da083027-fcd4-bc08-2d88-93034ba1cacc-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-23 23:51                     ` Casey Schaufler
2017-06-23 23:51                       ` Casey Schaufler
2017-06-23 23:51                       ` Casey Schaufler
2017-06-23 23:51                       ` Casey Schaufler
     [not found]             ` <3404c486-c848-3283-50f7-2283cb631e8e-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-23 18:35               ` Serge E. Hallyn
2017-06-28  5:41     ` Serge E. Hallyn
2017-06-28  5:41       ` Serge E. Hallyn
     [not found]       ` <20170628054138.GA15939-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-28  7:18         ` Amir Goldstein
2017-06-28  7:18       ` Amir Goldstein
2017-06-28  7:18         ` Amir Goldstein
2017-06-28 14:04         ` Stefan Berger
2017-06-28 14:04           ` Stefan Berger
2017-06-28 14:04           ` Stefan Berger
     [not found]         ` <CAOQ4uxhiSHEXzWN7=g-nmu=ebpv7hkXszW03JZ4UJkcjTeH+oQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-28 14:04           ` Stefan Berger
2017-06-28 14:28           ` Serge E. Hallyn
2017-06-28 14:28             ` Serge E. Hallyn
2017-06-28 14:28             ` Serge E. Hallyn
2017-06-28 14:28           ` Serge E. Hallyn
2017-06-28  5:41     ` Serge E. Hallyn
2017-06-23 20:09   ` Vivek Goyal
2017-06-23 20:09     ` Vivek Goyal
2017-06-23 20:09     ` Vivek Goyal
2017-06-23 20:09     ` Vivek Goyal
     [not found]     ` <20170623200956.GB24779-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-06-23 20:17       ` Serge E. Hallyn
2017-06-23 20:17     ` Serge E. Hallyn
2017-06-23 20:17       ` Serge E. Hallyn
2017-06-23 20:36       ` Vivek Goyal
2017-06-23 20:36         ` Vivek Goyal
2017-06-23 20:36         ` Vivek Goyal
2017-06-23 20:51         ` Serge E. Hallyn
2017-06-23 20:51           ` Serge E. Hallyn
     [not found]         ` <20170623203643.GC24779-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-06-23 20:51           ` Serge E. Hallyn
     [not found]       ` <20170623201723.GA22857-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 20:36         ` Vivek Goyal
2017-06-22 18:59 ` [PATCH 3/3] Enable security.selinux in user namespaces Stefan Berger
2017-06-22 18:59   ` Stefan Berger
2017-06-22 18:59   ` Stefan Berger
     [not found]   ` <1498157989-11814-4-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-23 20:30     ` Stephen Smalley
2017-06-23 20:30       ` Stephen Smalley
2017-06-23 20:30       ` Stephen Smalley
2017-06-23 20:30       ` Stephen Smalley
     [not found]       ` <1498249800.2063.9.camel-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>
2017-06-23 23:41         ` Stefan Berger
2017-06-23 23:41           ` Stefan Berger
2017-06-23 23:41           ` Stefan Berger
2017-06-23 23:41           ` Stefan Berger
2017-06-22 19:59 ` [PATCH 0/3] Enable namespaced file capabilities Casey Schaufler
2017-06-22 19:59   ` Casey Schaufler
2017-06-22 19:59   ` Casey Schaufler
2017-06-22 20:12   ` Stefan Berger
2017-06-22 20:12     ` Stefan Berger
2017-06-22 20:12     ` Stefan Berger
     [not found]     ` <10fb9c1b-e9af-336c-9a1b-cf95259cfaf3-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-22 20:33       ` Casey Schaufler
2017-06-22 20:33     ` Casey Schaufler
2017-06-22 20:33       ` Casey Schaufler
2017-06-22 20:33       ` Casey Schaufler
     [not found]       ` <2bf08b3e-27f4-3592-d5e2-a823401ac644-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-22 21:03         ` Stefan Berger
2017-06-22 21:03           ` Stefan Berger
2017-06-22 21:03           ` Stefan Berger
2017-06-22 21:03           ` Stefan Berger
2017-06-22 21:09         ` Serge E. Hallyn
2017-06-22 21:09           ` Serge E. Hallyn
2017-06-22 21:09           ` Serge E. Hallyn
2017-06-22 22:40           ` Casey Schaufler
2017-06-22 22:40             ` Casey Schaufler
2017-06-22 22:40             ` Casey Schaufler
     [not found]             ` <45e59e2e-0e00-cb9a-2f85-dc4606338a08-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-22 23:07               ` Serge E. Hallyn
2017-06-22 23:07             ` Serge E. Hallyn
2017-06-22 23:07               ` Serge E. Hallyn
     [not found]           ` <20170622210925.GA32691-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-22 22:40             ` Casey Schaufler
     [not found]   ` <70a09f1b-e82c-a25c-9325-d5d757b1b695-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-22 20:12     ` Stefan Berger
2017-06-22 23:29 ` James Bottomley [this message]
2017-06-22 23:29   ` James Bottomley
2017-06-22 23:29   ` James Bottomley
     [not found]   ` <1498174161.7636.4.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-06-22 23:32     ` Serge E. Hallyn
2017-06-22 23:36     ` Serge E. Hallyn
2017-06-22 23:32   ` Serge E. Hallyn
2017-06-22 23:32     ` Serge E. Hallyn
2017-06-22 23:36   ` Serge E. Hallyn
2017-06-22 23:36     ` Serge E. Hallyn
2017-06-23  0:13     ` James Bottomley
2017-06-23  0:13       ` James Bottomley
2017-06-23  0:13       ` James Bottomley
2017-06-23  1:19       ` Serge E. Hallyn
2017-06-23  1:19         ` Serge E. Hallyn
     [not found]       ` <1498176787.7636.11.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-06-23  1:19         ` Serge E. Hallyn
2017-06-23 17:37         ` Eric W. Biederman
2017-06-23 17:37       ` Eric W. Biederman
2017-06-23 17:37         ` Eric W. Biederman
2017-06-23 17:37         ` Eric W. Biederman
2017-06-23 18:39         ` Serge E. Hallyn
2017-06-23 18:39           ` Serge E. Hallyn
     [not found]         ` <87efuaip08.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-06-23 18:39           ` Serge E. Hallyn
     [not found]     ` <20170622233619.GC2894-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23  0:13       ` James Bottomley
  -- strict thread matches above, loose matches on Subject: below --
2017-06-22 18:59 Stefan Berger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1498174161.7636.4.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.