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. 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
