On Sunday, December 25, 2011 12:14:44 am Xin LI wrote: > Hi, Doug, > > On Sat, Dec 24, 2011 at 1:29 PM, Doug Barton <[email protected]> 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.
Can you give some more details on why ftpd is triggering a dlopen inside of the chroot? It would appear that that is unrelated to helper programs (since setting a flag in libc in ftpd can't possibly affect helper programs ability to use dlopen() from within libc). -- John Baldwin _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"
