[Pkg-shadow-devel] [test] newuidmap/newgidmap

[Serge Hallyn]

Quoting Philippe Grégoire (gregoirep at hotmail.com):
> On 2014-06-03 15:38:05 (+0000), Serge Hallyn wrote:
> > Quoting Philippe Grégoire (gregoirep at hotmail.com):
> > 
> > I personally still feel as you do, that root should be a special case who can
> > do as he likes;  OTOH it's not an unreasonable argument that (a) root can do
> > as he likes manually anyway, and (b) requiring this gives some default
> > protective isolation of subuids for root.
> 
> Actually, I believe that, because root can do arbitrary mappings using /proc,
> there is no _need_ for an exception.

So you're happy with the status quo?  (There is currently no exception, only
ranges authorized by /etc/subuid are allowed)

> The main goal here is to prevent collisions and privilege escalations if users
> were allowed to do arbitrary mappings. /etc/subuid allows just that by enabling
> users to do mappings (with the help of a SETUID program) to ranges specified by
> the administrator (or programmatically, in the case of adduser). While it is
> true that root can have subids, it cannot be enforced, utltimately, by
> newuidmap.

It can't be enforced.  However, noone except while playing around with it is
going to manually set up uid mappings.  They'll use a toolset, let's, oh, say,
lxc-usernsexec.  Not having this exception for root means that all such
toolsets will need to have a separate code path for the root user writing
to /proc/$$/uid_map, while the main code path uses newuidmap.  That's a
recipe for untested paths and errors.

> If one would want to enforce subids for root, one may want to investigate a
> /proc/.../subuid interface. That could probably leave the whole restriction

I'm not sure what you mean here.

> process in the kernel, remove the need for newuidmap and have the administrator
> allocate subuids for himself before using them.
> 
> In any case, the thing here is about assumptions. newuidmap is not a front-end
> but a dedicated tool.

A dedicated privileged tool for use by other tools, to localize the very careful
handling needed to delegate this stuff safely.

> To avoid confusion, the manual should be more factual and
> recommend checking the mapping with the kernel for a definitive answer.

I think you're saying you want an update to newuidmap(1), but I don't understand
what.  Can you give some proposed text?

> P. Grégoire

-serge