On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson wrote: >> On tis, 2015-03-31 at 17:08 +0300, James Bottomley wrote: >> > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski wrote: >> > > >> > > 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. >> >> That is controlled by the general rights to mount stuff. I.e. unless you >> have CAP_SYS_ADMIN in the VPS container you will not be able to mount >> devpts there. You can only do it in a subcontainer where you got >> permissions to mount via using user namespaces. > > OK let me try again. Fine, if you want to speak capabilities, you've > given a non-root user an unexpected capability (the capability of > creating a ptmx device). But you haven't used a capability separation > to do this, you've just hard coded it via a mount parameter mechanism. > > If you want to do this thing, do it properly, so it's acceptable to the > whole of Linux, not a special corner case for one particular type of > container. > > Security breaches are created when people code in special, little used, > corner cases because they don't get as thoroughly tested and inspected > as generally applicable mechanisms. > > What you want is to be able to use the tty subsystem as a non root user: > fine, but set that up globally, don't hide it in containers so a lot > fewer people care. I tend to agree, and not just for the tty subsystem. This is an attack surface issue. With unprivileged user namespaces, unprivileged users can create mount namespaces (probably a good thing for bind mounts, etc), network namespaces (reasonably safe by themselves), network interfaces and iptables rules (scary), fresh instances/superblocks of some filesystems (scariness depends on the fs -- tmpfs is probably fine), and more. I think we should have real controls for this, and this is mostly Eric's domain. Eric? A silly issue that sometimes prevents devpts from being mountable isn't a real control, though. --Andy > > James > > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
