On 12/23/2011 10:42, Alexander Kabaev wrote:
> On Fri, 23 Dec 2011 20:29:59 +0200
> Kostik Belousov <kostik...@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 <kostik...@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 <j...@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/
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
