Date: Sat, 24 Dec 2011 21:14:44 -0800 From: Xin LI <delphij@gmail.com> To: Doug Barton <dougb@freebsd.org> Cc: freebsd-security@freebsd.org Subject: Re: svn commit: r228843 - head/contrib/telnet/libtelnet head/crypto/heimdal/appl/telnet/libtelnet head/include head/lib/libc/gen head/lib/libc/iconv head/lib/libc/include head/lib/libc/net head/libexec... Message-ID: <CAGMYy3uzLXMvw40q1hM9dnHGxxh%2BeO_8Y1nbNKsPSB_Aenmm7w@mail.gmail.com> In-Reply-To: <4EF6444F.6090708@FreeBSD.org> References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <201112231058.46642.jhb@freebsd.org> <201112231122.34436.jhb@freebsd.org> <20111223120644.75fe944d@kan.dyndns.org> <20111223175143.GJ50300@deviant.kiev.zoral.com.ua> <20111224100509.GA98136@vniz.net> <CAGMYy3s4YM-j165o9p%2BEDgMf0%2BaJq7gKj5yR=LK8_yfECnbtog@mail.gmail.com> <20111224103948.GA10939@vniz.net> <CAGMYy3vUMUi0ajADs2AdVRPfWQShmjfXDHfrKTFBmHGiNTWPFA@mail.gmail.com> <20111224105045.GA11127@vniz.net> <8E5EE6FA-7BA1-4590-843A-F5C3C0493E5B@FreeBSD.org> <CAGMYy3u3ixg0rh16JFwL00a%2BH-qGb60LTR2tLgCrRXfAhMrvFA@mail.gmail.com> <4EF6444F.6090708@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Doug, On Sat, Dec 24, 2011 at 1:29 PM, Doug Barton <dougb@freebsd.org> wrote: > On 12/24/2011 12:46, Xin LI wrote: >> Won't work because the binary might be run by privileged but chroot >> user. Again, this is the first proposal that we have considered. > > Now that the cat is out of the bag, and a fix is available, might it not > make sense to summarize the private discussions about this issue > somewhere, and brainstorm about a better solution? I'd suggest -hackers, > or perhaps -security as good public lists to do this on. > > A quick writeup along the lines of, "Here are the ideas we considered, > and here is why we rejected them" would jump-start the discussion, and > perhaps ease the frustration of the people who are just now looking at > this and scratching their heads. > > I understand why the previous discussion was undertaken privately, but > there is no need to continue the secrecy any longer. Here are the ideas we have came with patches and get dropped for some reason (not solving all problems, cause incompatibility issue, etc): a) Have dynamic linker check permissions (w^x policy) on shared library when program was setuid; b) Have nsdispatch(3) check permissions on configuration files; c) Have a dlopen(3) wrapper that have a flag that allows caller to say "this is security sensitive and don't load libraries that have suspicious permissions" d) Completely disable nsdispatch reload feature; e) The current version; f) The current version but with a wrapper around chroot(2) that disables all libc dlopen(3) calls; g) The current version with libc_dlopen(3) exposed as a new API as well and/or have the ugly API exposed in FBSD_1.2 namespace. This is primarily trivial cleanup changes and both were denied. Requirement were: - Must not break existing and legitimate use of chroot(2), in other words no semantics change permitted. - Must fix the ftpd(8) issue itself since it's already public. - Must not break anything other than the attack, e.g. require additional steps other than patching. Cheers, -- Xin LI <delphij@delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGMYy3uzLXMvw40q1hM9dnHGxxh%2BeO_8Y1nbNKsPSB_Aenmm7w>