From owner-svn-src-all@FreeBSD.ORG Sat Dec 24 08:20:22 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 54C751065675; Sat, 24 Dec 2011 08:20:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4117714FBF9; Sat, 24 Dec 2011 08:20:15 +0000 (UTC) Message-ID: <4EF58B3E.3090408@FreeBSD.org> Date: Sat, 24 Dec 2011 00:20:14 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Xin LI 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> <4EF51AA8.5040702@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, John Baldwin , svn-src-all@freebsd.org, svn-src-head@freebsd.org, Colin Percival , Kostik Belousov , Alexander Kabaev 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... X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 08:20:22 -0000 On 12/23/2011 20:22, Xin LI wrote: > On Fri, Dec 23, 2011 at 4:19 PM, Doug Barton wrote: >> On 12/23/2011 10:42, Alexander Kabaev wrote: >>> On Fri, 23 Dec 2011 20:29:59 +0200 >>> Kostik Belousov 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 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 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. > > That's correct, this affects ALL applications that does chroot into a > hostile environment where /etc and /lib can be controlled by > unprivileged user, which is in my opinion fundamentally insecure in > the first place. So now I'm confused. We're applying this ugly hack to libc in order to save system administrators who do blatantly stupid things? -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/