All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
To: Linux Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	util-linux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	systemd-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Unprivileged containers and co-ordinating user namespaces
Date: Thu, 28 Apr 2016 15:02:08 -0700	[thread overview]
Message-ID: <1461880928.2307.48.camel@HansenPartnership.com> (raw)

It's always been annoying to me that we never co-ordinate our use of
namespace resources, but it's never really mattered until the user
namespace came along because namespaces didn't overlap and the only
annoyance was not being able to use existing tools to manipulate other
containers (mainly not being able to us ip netns).

However, with the user namespace, it's become necessary to co-ordinate
if you're giving users a range of uids beyond their own because you
don't want to have two separate container users owning overlapping uid
numbers (especially if they're unprivileged) because that will lead to
all sorts of security issues.  I think we need two things: a file
describing this for other things (like container orchestration systems
that want to know) and a mechanism for delegating the alloted uids to
the user.  One possible way of doing this would be to have the init
system set up the correctly owned user namespace at boot time.  It's
appealing to have the user sort out their own administration by simply
spawning new child user namespaces, but it adds the complexity that we
have to know what we're mapping to inside the namespace, whereas all
the administrator really cares about is what exterior uid range is
allocated (and that it remain that same range between reboots, because
these are the uids that's going to appear on disk).

Assuming everyone agrees it's a file and a utility, I'd propose the
file be

/etc/usernamespaces

and the format be <user>:<start>:<length>:<flags>

For the allocated uids.  <user>,<start> and <length> are obvious but
<flags> would be used for things like deny setgroups and possibly other
privilege reductions.

Then we need a utility, say userns that has cap_setuid+cap_setgid and
takes as an argument the raw uid_map, gid_map the user wants to install
plus similar arguments to unshare.  It then validates that the exterior
range are allowed by /etc/usernamespaces and sets up the usernamespace
with that range owned by the invoking user.

Container orchestration systems can either register their (probably
huge) ranges in the file, or simply use the file to know what ranges to
avoid.

If this sounds OK to people, I can code up a utility that does this,
which should probably belong in util-linux.

James

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Linux Containers <containers@lists.linux-foundation.org>,
	util-linux@vger.kernel.org, systemd-devel@lists.freedesktop.org
Subject: Unprivileged containers and co-ordinating user namespaces
Date: Thu, 28 Apr 2016 15:02:08 -0700	[thread overview]
Message-ID: <1461880928.2307.48.camel@HansenPartnership.com> (raw)

It's always been annoying to me that we never co-ordinate our use of
namespace resources, but it's never really mattered until the user
namespace came along because namespaces didn't overlap and the only
annoyance was not being able to use existing tools to manipulate other
containers (mainly not being able to us ip netns).

However, with the user namespace, it's become necessary to co-ordinate
if you're giving users a range of uids beyond their own because you
don't want to have two separate container users owning overlapping uid
numbers (especially if they're unprivileged) because that will lead to
all sorts of security issues.  I think we need two things: a file
describing this for other things (like container orchestration systems
that want to know) and a mechanism for delegating the alloted uids to
the user.  One possible way of doing this would be to have the init
system set up the correctly owned user namespace at boot time.  It's
appealing to have the user sort out their own administration by simply
spawning new child user namespaces, but it adds the complexity that we
have to know what we're mapping to inside the namespace, whereas all
the administrator really cares about is what exterior uid range is
allocated (and that it remain that same range between reboots, because
these are the uids that's going to appear on disk).

Assuming everyone agrees it's a file and a utility, I'd propose the
file be

/etc/usernamespaces

and the format be <user>:<start>:<length>:<flags>

For the allocated uids.  <user>,<start> and <length> are obvious but
<flags> would be used for things like deny setgroups and possibly other
privilege reductions.

Then we need a utility, say userns that has cap_setuid+cap_setgid and
takes as an argument the raw uid_map, gid_map the user wants to install
plus similar arguments to unshare.  It then validates that the exterior
range are allowed by /etc/usernamespaces and sets up the usernamespace
with that range owned by the invoking user.

Container orchestration systems can either register their (probably
huge) ranges in the file, or simply use the file to know what ranges to
avoid.

If this sounds OK to people, I can code up a utility that does this,
which should probably belong in util-linux.

James


             reply	other threads:[~2016-04-28 22:02 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-28 22:02 James Bottomley [this message]
2016-04-28 22:02 ` Unprivileged containers and co-ordinating user namespaces James Bottomley
     [not found] ` <1461880928.2307.48.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-04-28 23:00   ` W. Trevor King
2016-04-28 23:00     ` W. Trevor King
     [not found]     ` <20160428230045.GS22888-q4NCUed9G3sTnwFZoN752g@public.gmane.org>
2016-04-29 15:38       ` James Bottomley
2016-04-29 15:38         ` James Bottomley
2016-04-29 15:53         ` Serge E. Hallyn
     [not found]           ` <20160429155303.GA8900-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2016-04-29 18:34             ` W. Trevor King
2016-04-29 18:34               ` W. Trevor King
2016-04-29 21:50               ` Serge E. Hallyn
     [not found]               ` <20160429183404.GE22888-q4NCUed9G3sTnwFZoN752g@public.gmane.org>
2016-04-29 21:50                 ` Serge E. Hallyn
2016-04-29 22:18         ` James Bottomley
     [not found]           ` <1461968310.16292.20.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-05-01 16:37             ` Serge Hallyn
2016-05-01 16:37           ` Serge Hallyn
2016-05-01 23:29             ` James Bottomley
     [not found]               ` <1462145366.2337.18.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-05-02  4:13                 ` Serge E. Hallyn
2016-05-02  4:13                   ` Serge E. Hallyn
2016-05-01 23:29             ` James Bottomley
     [not found]         ` <1461944328.2311.10.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-04-29 15:53           ` Serge E. Hallyn
2016-04-29 22:18           ` James Bottomley
2016-05-04 15:02           ` Eric W. Biederman
2016-05-04 15:02         ` Eric W. Biederman
     [not found]           ` <87wpn9988a.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-05-04 15:21             ` Phil Estes
2016-05-04 18:17             ` James Bottomley
2016-05-04 15:21           ` Phil Estes
2016-05-04 18:17           ` James Bottomley
2016-05-04 18:21             ` James Bottomley
     [not found]             ` <1462385876.14310.90.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-05-04 18:21               ` James Bottomley

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=1461880928.2307.48.camel@HansenPartnership.com \
    --to=james.bottomley-d9phhud1jfjcxq6kfmz53/egyhegw8jk@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=systemd-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=util-linux-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.