Guidance on solving the username namespacing problem

[Simon McVittie]

On Sun, 05 Jan 2020 at 17:16:58 +0100, Philipp Kern wrote:
> On 1/4/2020 5:08 PM, Simon McVittie wrote:
> > It's also worth noting that the 61184-65519 uid range used for DynamicUser
> > by default collides with the rarely-used 60000-64999 uid range for system
> > users that are "globally allocated by the Debian project, but only created
> > on demand".
> > 
> > The uids in range 60000-64999 that are really allocated in practice are
> > in the sub-range 64000-64062, except for 63434 'netplan' which appears
> > to be for an orphaned package that isn't in testing; so it might be
> > feasible to reconfigure the DynamicUser range to 60000-63999 or similar
> > in Debian's systemd?
> 
> It looks like the range must be contiguous, as it is compiled in[1].

Yes.

> What are the preexisting ones apart from netplan that you have in mind?

https://sources.debian.org/src/base-passwd/3.5.47/README/#L28

As you can see, apart from netplan (63434, which I suspect may have been
imported from a previous ad-hoc allocation) in practice they are all in
the 640xx range. Most of the newer allocations seem to be cluster/cloud
services where having the same uid across a whole cluster is
desirable: the vast majority of system services are fine with the
dynamically-allocated 100-999 range.

> It feels like systemd's boundaries are pretty arbitrary (0xEF00 to
> 0xFFEF) but at the same time we might want to reserve a range for it in
> policy - given that right now it is effectively squatting in that range?

Yes, I think so.

The exact range used seems to be arbitrary, and having a slightly smaller
range in Debian would probably be OK, as long as it isn't orders of
magnitude smaller?

> The main argument presented by upstream is that it needs to be within
> 64bit for user namespacing to work properly.

I assume you meant within the 16-bit range (first 64k uids), but yes. The
big idea is that container number 0x1234 can have uids ranging from
0x12340000 (root in the container) to 0x1234fffe ('nobody' in the
container, where 'nobody' is 65534 = 0xfffe), which avoids the problem
seen in e.g. Docker where uid 1000 in container A can sometimes
unintentionally get privileges over processes owned by uid 1000 in
container B, because they are both uid 1000 on the host system.

Managing uid and gid allocations for containers seems likely to be
much, much easier if each container gets a linear block of 65535 uids
within which it can use the entire legacy 16-bit uid space, rather than
having a discontinuous uid range so that some uids are unavailable to
the container.

    smcv