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...

[Xin LI]

2011/12/24 Edward Tomasz Napierała <trasz at freebsd.org>:
> Wiadomość napisana przez Andrey Chernov w dniu 24 gru 2011, o godz. 11:50:
>> On Sat, Dec 24, 2011 at 02:45:21AM -0800, Xin LI wrote:
>>> On Sat, Dec 24, 2011 at 2:39 AM, Andrey Chernov <ache at freebsd.org> wrote:
>>>> On Sat, Dec 24, 2011 at 02:26:20AM -0800, Xin LI wrote:
>>>>> chroot(2) can create legitimate and secure environment where dlopen(2)
>>>>> is safe and necessary.
>>>>
>>>> Yes, so ischroot() check can be used only into that places where libc's
>>>> libc_dlopen() currently used, i.e. placed into libc_dlopen() itself.
>>>
>>> So it's Okay to break NSS in chroot jail?
>>
>> We need general solution. We simple can't count all possible and future
>> ftpd's arround the world and insert __FreeBSD_libc_enter_restricted_mode()
>> into them. I even not mention other programs that may use chroot() too. If
>> some component like auth is critical for chroot, it should be restricted
>> in general scope.
>
> How about adding a check in dlopen(3) to make sure the file being opened
> is owned either by us (getuid(3)) or root and is not writable by anyone else?

Won't work because the binary might be run by privileged but chroot
user.  Again, this is the first proposal that we have considered.

Cheers,
-- 
Xin LI <delphij at delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die