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]

Hi, Doug,

On Sat, Dec 24, 2011 at 1:29 PM, Doug Barton <dougb at freebsd.org> wrote:
> On 12/24/2011 12:46, Xin LI wrote:
>> Won't work because the binary might be run by privileged but chroot
>> user.  Again, this is the first proposal that we have considered.
>
> Now that the cat is out of the bag, and a fix is available, might it not
> make sense to summarize the private discussions about this issue
> somewhere, and brainstorm about a better solution? I'd suggest -hackers,
> or perhaps -security as good public lists to do this on.
>
> A quick writeup along the lines of, "Here are the ideas we considered,
> and here is why we rejected them" would jump-start the discussion, and
> perhaps ease the frustration of the people who are just now looking at
> this and scratching their heads.
>
> I understand why the previous discussion was undertaken privately, but
> there is no need to continue the secrecy any longer.

Here are the ideas we have came with patches and get dropped for some
reason (not solving all problems, cause incompatibility issue, etc):

a) Have dynamic linker check permissions (w^x policy) on shared
library when program was setuid;
b) Have nsdispatch(3) check permissions on configuration files;
c) Have a dlopen(3) wrapper that have a flag that allows caller to say
"this is security sensitive and don't load libraries that have
suspicious permissions"
d) Completely disable nsdispatch reload feature;
e) The current version;
f) The current version but with a wrapper around chroot(2) that
disables all libc dlopen(3) calls;
g) The current version with libc_dlopen(3) exposed as a new API as
well and/or have the ugly API exposed in FBSD_1.2 namespace.  This is
primarily trivial cleanup changes and both were denied.

Requirement were:

 - Must not break existing and legitimate use of chroot(2), in other
words no semantics change permitted.
 - Must fix the ftpd(8) issue itself since it's already public.
 - Must not break anything other than the attack, e.g. require
additional steps other than patching.

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