[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Feb 2016 05:27:38 +0000
From: halfdog <me@...fdog.net>
To: oss-security@...ts.openwall.com
Subject: Re: Access to /dev/pts devices via pt_chown and user
namespaces
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Solar Designer wrote:
>> With Ubuntu Wily and earlier, /usr/lib/pt_chown was used to
>> change ownership of slave pts devices in /dev/pts to the same uid
>> holding the master file descriptor for the slave.
>
> I think pt_chown is only needed for legacy BSD pty's, and no
> longer needed for Unix 98 pty's that Linux systems use these days.
> Perhaps it should be dropped from upstream glibc by now. e.g. on
> Owl we haven't been installing it SUID ever (as it was already
> legacy 15 years ago), and we haven't been packaging it at all since
> 2005.
That is nice, that this was done already for OWL. Is there a checklist
or perhaps even a tool, that can be run, to detect, which weak
programs, compile time settings or runtime settings might be applied
to a given Linux setup?
Vulnerability scanners do that, is there some kind of consensus, which
scanner implementation might already suit our needs best and hence
could be filled with test scripts?
With such procedure in place, I would find it a little bit
non-cooperative, if just one distribution fixes a weakness, but does
not tell others. This should put soft pressure on all of us to have
this list up to date. In my opinion, this procedure should also
include, that each distribution just with the slightest aim to provide
secure Linux installation should run this tool and give single line
risk argument for each of the points found (e.g. pt_chown needed for
legacy XXX-server - then community would know reason and perhaps where
to start fixing). If distros do not want to do run the analysis and
annotate it, those reports should be collected to build some kind of
distro-ranking where community will anotate.
So
a) should we put such a framework (tool) and procedure in place?
b) is there already both in place?
c) if not, which framework would suite best?
d) already a procedure in place?
>> In my opinion, this security bug should be fixed two-fold: At
>> first, kernel should prevent the TIOCGPTN ioctl when invoked
>> called by a process within one namespace but acting on a
>> filedescriptor from a devpts instance mounted in a different
>> namespace. Additionally pt_chown should check via readlink and
>> stat, that the passed file descriptor really was from the
>> /dev/ptmx or /dev/pts/ptmx device present in the same namespace
>> as the /dev/pts/[num] device is residing. This of course is only
>> relevant if pt_chown is going to survive on recent namespace
>> aware systems.
>
> I think the primary fixes should be different: disable unprivileged
> user namespaces by default, and drop pt_chown.
I did not know, that pt_chown is completely obsolete by itself. So
pt_chown should be dead. About unprivileged userns: That is also why I
proposed deactivation on distro-list. I just do not get it, why there
is so much resistance to make it configurable.
>> Timeline: =========
>>
>> 20151220: Discovery 20151227: Report at Ubuntu Launchpad1529486
>> 20160104: Report to distros list 20160122: Patch to disable
>> unprivileged userns due to this and other issues LKML 20160222:
>> CRD and publication
>
> Ouch. As you're aware, everything you report to distros must be
> made public in at most 2 weeks. Unfortunately, I didn't keep track
> of this, and I don't recall if your report to distros included the
> detail you're disclosing just today. I thought you had already
> disclosed whatever was on distros here:
>
> http://www.openwall.com/lists/oss-security/2016/01/19/17
>
> Now I see you were asking for advice on further handling of these
> issues in there, and got no replies. :-(
>
> I think going forward, you shouldn't make any use of the distros
> list, and should post to oss-security right away.
OK, I will do that, of course leaving out the exploit code for 2
weeks, so that this disclosure procedure has similar timing for
exploit availability compared to sharing via distro-list.
>> References: ===========
>>
>> [0]
>> http://www.halfdog.net/Security/2015/PtChownArbitraryPtsAccessViaUserNamespace/
>>
>>
[1]
>> http://www.halfdog.net/Security/2016/OverlayfsOverFusePrivilegeEscalation/
>
>>
> In [0], "LKML" points to:
>
> https://lkml.org/lkml/2016/1/22/7
>
> Unfortunately, that archive of LKML is currently broken (doesn't
> display the actual message to me), so I don't know what exactly
> this was.
Strange, did not notice, that they are not serving.
> I did, however, watch the discussion CC'ed to kernel-hardening,
> where Kees Cook proposed "sysctl: allow CLONE_NEWUSER to be
> disabled":
[This is exactly the same discussion.]
> http://www.openwall.com/lists/kernel-hardening/2016/01/22/19
> http://www.openwall.com/lists/kernel-hardening/2016/01/22/20
> http://www.openwall.com/lists/kernel-hardening/2016/01/22/21
>
> Unfortunately, this was NAK'ed by the maintainer, Eric W.
> Biederman:
>
> http://www.openwall.com/lists/kernel-hardening/2016/01/23/4
> http://www.openwall.com/lists/kernel-hardening/2016/01/25/11
> http://www.openwall.com/lists/kernel-hardening/2016/01/26/7
>
> Eric suggested "a per user limit on the number of user namespaces
> users may create". There was some further discussion after that
> point, but no clear outcome. Last message posted on January 28.
Yes, I read that. But why? Does Linux kernel team fear to annoy some
developers, that put their own blood into getting unprivileged USERNS
working, by now again disabling part of their work by default?
It just seems to me, that the discussion is not on the technical
matter, how to introduce an effective switch quickly. Otherwise some
primitive scheme with forward compatibility should be chosen right
immediately. (e.g. "off" for complete disable "on" for complete enable
and all other variants, e.g. userlist, maxlevels, ... later on). Slow
action might be seen by some folks as irresponsible regarding
security, hence harming the idea of Linux as free and secure operating
system.
hd
- --
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlbNPz4ACgkQxFmThv7tq+63AQCfTpcIQC6eNCQprZ+BJrTVnV28
+PMAnRtc87eyPU8pHy58lF2TJIiQJH/2
=0+3d
-----END PGP SIGNATURE-----
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.
