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

[Andy Lutomirski]

On Tue, Mar 31, 2015 at 6:55 AM, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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.

--Andy

>  It will effectively relax security of a VPS container which is
> highly undesirable.  We need the security of an operating system
> container to be the same as it would be for an unvirtualized operating
> system otherwise people get nasty surprises.
>
> The fact that container root can mount /dev/ptmx is fine to me, because
> container root is a privileged user inside the container.  There's still
> no way, short of a privilege escalation, than a non-root container user
> can become container root.
>
> James
>
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/