All of lore.kernel.org
 help / color / mirror / Atom feed
* Unprivileged containers and co-ordinating user namespaces
@ 2016-04-28 22:02 ` James Bottomley
  0 siblings, 0 replies; 28+ messages in thread
From: James Bottomley @ 2016-04-28 22:02 UTC (permalink / raw)
  To: Linux Containers, util-linux-u79uwXL29TY76Z2rM5mHXA,
	systemd-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2016-05-04 18:21 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-28 22:02 Unprivileged containers and co-ordinating user namespaces James Bottomley
2016-04-28 22:02 ` 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
     [not found]               ` <20160429183404.GE22888-q4NCUed9G3sTnwFZoN752g@public.gmane.org>
2016-04-29 21:50                 ` Serge E. Hallyn
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
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
     [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
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
     [not found]           ` <87wpn9988a.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-05-04 15:21             ` Phil Estes
2016-05-04 18:17             ` James Bottomley

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.