Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Dec 2011 00:20:14 -0800
From:      Doug Barton <dougb@FreeBSD.org>
To:        Xin LI <delphij@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>, Alexander Kabaev <kabaev@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:  <4EF58B3E.3090408@FreeBSD.org>
In-Reply-To: <CAGMYy3t1bQNGFpef0FGmSS0nAOoPnqOy6y5K-JJvLhaOejJ1cA@mail.gmail.com>
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> <CAGMYy3t1bQNGFpef0FGmSS0nAOoPnqOy6y5K-JJvLhaOejJ1cA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12/23/2011 20:22, Xin LI wrote:
> On Fri, Dec 23, 2011 at 4:19 PM, Doug Barton <dougb@freebsd.org> wrote:
>> 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.
> 
> 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/




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF58B3E.3090408>