From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754868AbbCaNpU (ORCPT ); Tue, 31 Mar 2015 09:45:20 -0400 Received: from mail-la0-f47.google.com ([209.85.215.47]:33416 "EHLO mail-la0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754670AbbCaNpB (ORCPT ); Tue, 31 Mar 2015 09:45:01 -0400 MIME-Version: 1.0 In-Reply-To: <1427808184.2117.122.camel@HansenPartnership.com> References: <1427447013.2250.9.camel@HansenPartnership.com> <1427788642.4411.12.camel@redhat.com> <1427807248.2117.117.camel@HansenPartnership.com> <1427808184.2117.122.camel@HansenPartnership.com> From: Andy Lutomirski Date: Tue, 31 Mar 2015 06:44:39 -0700 Message-ID: Subject: Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options To: James Bottomley Cc: Alexander Larsson , gnome-os-list@gnome.org, Linux Containers , "linux-kernel@vger.kernel.org" , mclasen@redhat.com, "Eric W. Biederman" , Linux FS Devel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 31, 2015 at 6:23 AM, James Bottomley wrote: > On Tue, 2015-03-31 at 06:12 -0700, Andy Lutomirski wrote: >> On Tue, Mar 31, 2015 at 6:07 AM, James Bottomley >> 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 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