[PATCH] devpts: Add ptmx_uid and ptmx_gid options

Andy Lutomirski luto at amacapital.net
Thu Apr 2 14:06:06 UTC 2015

On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
<James.Bottomley at hansenpartnership.com> 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.


> James

Andy Lutomirski
AMA Capital Management, LLC

More information about the Containers mailing list