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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote:
> On Tue, Mar 31, 2015 at 6:55 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Tue, 2015-03-31 at 06:44 -0700, Andy Lutomirski wrote:
> >> 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.
> >
> > Yes, I know.  However remember we use containers to host VPSs which
> > themselves can have non-root users.  I don't want a non root user inside
> > the VPS to be able to muck with the tty subsystem.  Your patch allows
> > that.
> 
> I don't think that this is correct.  That user can already create a
> nested userns and map themselves as 0 inside it.  Then they can mount
> devpts.

I don't mind if they create a container and control the isolated ttys in
that sub container in the VPS; that's fine.  I do mind if they get
access to the ttys in the VPS.

If you can convince me (and the rest of Linux) that the tty subsystem
should be mountable by an unprivileged user generally, then what you
propose is OK.

James