[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160224191054.GD19242@ubuntumail>
Date: Wed, 24 Feb 2016 19:10:54 +0000
From: Serge Hallyn <serge.hallyn@...ntu.com>
To: oss-security@...ts.openwall.com
Subject: Re: Access to /dev/pts devices via pt_chown and user
namespaces
Quoting Dmitry V. Levin (ldv@...linux.org):
> On Wed, Feb 24, 2016 at 07:01:11AM +0000, Simon McVittie wrote:
> [...]
> > <https://bugs.debian.org/717544> has some interesting background. The
> > Debian and Ubuntu glibc maintainers tried turning off pt_chown in 2014,
> > but had to turn it back on because it caused too many regressions: in
> > particular "mount -t devpts devpts-foo chroot-foo/dev/pts" apparently
> > alters the mount options for the "real" /dev/pts, not just the one being
> > mounted in the chroot (presumably losing the noexec,nosuid,gid=5 and
> > mode=620 or mode=600 options that are expected in Debian). I don't know
> > whether the default mount options were subsequently altered in util-linux
> > and/or the kernel as suggested on that bug, or whether manually mounting
> > devpts is just not going to be a supported action in Debian 9.
>
> Linux kernel, starting with version 2.6.29, allows multiple instances
> of devpts filesystem (assuming that CONFIG_DEVPTS_MULTIPLE_INSTANCES
> is enabled) when "newinstance" mount option is specified for devpts.
> The feature is primarily to support containers, but also addresses
> the issue:
> https://www.kernel.org/doc/Documentation/filesystems/devpts.txt
The problem is that while it's possible to mount a newinstance, it
is also still possible to mount the host instance and change the
settings. Any rogue piece of userspace in a non-user-namespaced
container is able to do so and mess up the host. If new devpts
mounts always did newinstance, then I think things would have been
different. But the mere availability of newinstance mounts does not
solve this.
(When the newinstance was being implemented the authors really did want
to make it so that future mounts would remount the 'namespaced' version,
(i.e. mount -t devpts -o newinstance /mnt; mount -t devpts /dev/pts
would result in /mnt's superblock being used for /dev/pts), but there
just wasn't a good way to figure out which mount that would be.)
-serge
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
