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

[Eric W. Biederman]

Serge Hallyn <serge.hallyn at ubuntu.com> writes:

> Quoting Eric W. Biederman (ebiederm at xmission.com):
>> Serge Hallyn <serge.hallyn at ubuntu.com> writes:
>> 
>> > 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.
>> 
>> But it is not.
>
> Agreed since we can allocate ranges for root as for anyone else it's
> fine.
>
> Which leaves only,
>
>> Root should be documenting which uids root uses in containers in
>> /etc/subuid just like everyone else.  That will allow sysadmins
>> to figure out what is going on.
>> 
>> So if you document what is going on, the only case that will fail for
>> root are for uids that you did not intend to use.  I don't see that as a
>> bad thing, and certainly I don't see it impeding code reuse.
>> 
>> Why should root owned containers be special and not have to document
>> which uids they use?
>
> Because root is special, and people expect that they can just do things
> as root, especially if the kernel doesn't prevent it.

I don't think newuidmap is at all the interface for just doing things.
It is the interface to keep it straight who is doing what.

If you want to provide an interface to just doing things (usually
connected to a -f or --force) command line argument I suspect just
writing to /proc/<pid>/uidmap.

> I'm not saying this pursuades me.  I'm saying I consider this only as
> valid of an argument as the below.

The extra bit is since newuidmap is setuid we really want to keep it as
simple and as straight forward as possible.  I think the reduction in
program logic of a suid application seems to justify not adding an
extra if statement.

It is far less scary to have a bug in an application that has isn't
setuid than it is to have a bug in an application that is suid.

>> Why should root owned containers not have to worry
>> about using uids that someone is using for something else?
>
> They very much do have to, which I've always said is the flipside
> argument.  That it is useful for protecting root from unpriv users.

Which is I why I reach the point scratching my head on this issue.

Eric