Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski <luto amacapital net>]

On Tue, Mar 31, 2015 at 6:23 AM, James Bottomley
<James Bottomley hansenpartnership com> wrote:
> On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote:
> > On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley
> > <James Bottomley hansenpartnership com> wrote:
> > > On Tue, 2015-03-31 at 09:57 +0200, Alexander Larsson wrote:
> > > > On fre, 2015-03-27 at 10:03 +0100, James Bottomley
> > > > > > On Fri, Feb 20, 2015 at 5:04 PM, Andy Lutomirski <luto amacapital net> wrote:
> > > > > > > It's currently impossible to mount devpts in a user namespace that
> > > > > > > has no root user, since ptmx can't be created.
> > > > >
> > > > > This is where I stopped reading because it's not true ... because it is
> > > > > possible, you just do it from the host as real root.
> > > >
> > > > The point is being able to set up a container as a user, not requiring
> > > > the setup to be run as root at all. In my case container is a desktop
> > > > application which will be started by the user, and will run as the user.
> > > > There is no root involved in the call chain at all.
> > >
> > > I don't really like that use case:  Most container setups are under the
> > > control of an orchestration system (like LXC, OpenVZ or even Docker).
> > > You typically get the orchestration system to do the dangerous
> > > operations (mount being one of the bigger dangers) because it has the
> > > capacity to vet them.  I can see the value in allowing a user to set up
> > > a container without an oversight system, but at the same time you're
> > > increasing the security vulnerability of the system.  Security is often
> > > a result of policy, so now this embeds policy into the kernel.  I
> > > strongly feel we should define the list of things we expect an
> > > unsupervised (as in with no orchestration system) container to do and
> > > then revisit this once we've given it some thought.
> >
> > Try thinking "sandbox", not "container".  The ability to create
> > sandboxes without some root-installed orchestration is incredibly
> > valuable.
>
> A container is anything that uses the various container APIs (mostly
> cgroups and namespaces), so the set of possible containers overlaps the
> set of possible sandboxes.
>
> > In any event, this ship sailed quite awhile ago.  devpts is one of the
> > smallish number of important missing features.
>
> I'm not saying "don't do it" I'm saying think carefully about the
> allowable features we permit an unprivileged user to take advantage of.
> This one feels strange to me in that you're asking to give an
> unprivileged user in a container more abilities than an unprivileged
> user outside a container (a non-root user can't mount /dev/ptmx today).
> This would mean that every unprivileged container user can now interfere
> with the tty subsystem.

That is true, but this is already the case.  The current code is:

        root_uid = make_kuid(current_user_ns(), 0);
        root_gid = make_kgid(current_user_ns(), 0);

Unprivileged tasks can make a userns and map themselves as "0" inside,
at which point the code I quoted will work fine.  The failure only
happens if they opt not to map anything at all as "0", as many
sandboxes will do.

--Andy