Date: Fri, 23 Dec 2011 16:19:52 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Colin Percival <cperciva@freebsd.org>, Kostik Belousov <kostikbel@gmail.com> 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: <4EF51AA8.5040702@FreeBSD.org> In-Reply-To: <20111223134225.11ac22fd@kan.dyndns.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> <20111223132034.12192baa@kan.dyndns.org> <20111223182959.GL50300@deviant.kiev.zoral.com.ua> <20111223134225.11ac22fd@kan.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/23/2011 10:42, Alexander Kabaev wrote: > On Fri, 23 Dec 2011 20:29:59 +0200 > Kostik Belousov <kostikbel@gmail.com> wrote: > >> On Fri, Dec 23, 2011 at 01:20:34PM -0500, Alexander Kabaev wrote: >>> On Fri, 23 Dec 2011 19:51:43 +0200 >>> Kostik Belousov <kostikbel@gmail.com> wrote: >>> >>>> On Fri, Dec 23, 2011 at 12:06:44PM -0500, Alexander Kabaev wrote: >>>>> On Fri, 23 Dec 2011 11:22:34 -0500 >>>>> John Baldwin <jhb@freebsd.org> wrote: >>>>> >>>>>> On Friday, December 23, 2011 10:58:46 am John Baldwin wrote: >>>>>>> On Friday, December 23, 2011 10:00:38 am Colin Percival >>>>>>> wrote: >>>>>>>> Author: cperciva >>>>>>>> Date: Fri Dec 23 15:00:37 2011 >>>>>>>> New Revision: 228843 >>>>>>>> URL: http://svn.freebsd.org/changeset/base/228843 >>>>>>>> >>>>>>>> Log: >>>>>>>> Fix a problem whereby a corrupt DNS record can cause >>>>>>>> named to crash. [11:06] >>>>>>>> Add an API for alerting internal libc routines to the >>>>>>>> presence of "unsafe" paths post-chroot, and use it in >>>>>>>> ftpd. [11:07] >>>>>>> >>>>>>> Eh, the whole libc_dlopen() thing looks like a gross hack >>>>>>> (and who came up with that weird symbol name for a public >>>>>>> API????). Is it really even needed given the other fix to >>>>>>> have ftpd drop privilege before execing a helper program? >>>>>>> I guess the main reason I don't like it is it doesn't do >>>>>>> anything to address the more general problem. I would have >>>>>>> expected instead something to restrict dlopen() entirely >>>>>>> including from other libraries than just libc in certain >>>>>>> circumstances. >>>>>> >>>>>> At the very least if we feel that the libc_dlopen() thing is a >>>>>> temporary band-aid, we should move the new symbols into the >>>>>> private namespace so we can remove them once the better fix >>>>>> is in rather than being required to support them forever. >>>> libc_dlopen() is not exposed. >>>> The __FreeBSD_libc_enter_restricted_mode() is, and its name is >>>> ugly exactly to note the ugly intent. I do not see how the symbol >>>> can go int FBSDprivate_1.0 when it was supposed to be used by >>>> third-party applications. >>>> >>>> Putting this hack into rtld itself IMO has to wide consequences. >>>> For libc, we can enumerate the points that stop work after the >>>> call, but for the generic applications the consequences are >>>> undefined. >>>>>> >>>>>> -- >>>>>> John Baldwin >>>>> >>>>> Pardon for not catching that when I had a chance to influence >>>>> the outcome, but I would like to voice my support to tucking the >>>>> ugliness into private version namespace. >>>>> >>>>> -- >>>>> Alexander Kabaev >>>> >>> Putting symbol into official namespace implies that we are willing >>> to provide and maintain it forever, which I do not think was the >>> intent for the function in question. FBSD_PRIVATE says nothing >>> about who should and should not link to it, only the level of API >>> stability one has to expect in the end. If/when we have better >>> security mechanisms (capsicum?) available to users by default, this >>> should be ripped out with extreme prejudice. >> >> The API is offered as a solution to third-parties. Telling them to use >> the API that is known to be broken in future is wrong step for the >> project, IMO. >> >> I doubt that proftpd will 'go capsicum'. > > Then proftp will have to contend with being known security hazard. > Spamming every supported branch with the symbol that cries just to > support programs that chroot into arbitrary environments and trust > anything at all there is wrong step for the project. Committing to > support said symbol for all of the eternity is even bigger mistake. I agree with those that have concerns about this solution. It seems ugly and painful, and if the vulnerability is so fundamental to chroot and/or nsdispatch then it seems that more than ftp would be affected. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF51AA8.5040702>