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