Date: Thu, 19 Feb 2015 23:25:01 -0800 From: Paul Pluzhnikov <ppluzhnikov@...gle.com> To: Tim Brown <tmb@...35.com> Cc: oss-security@...ts.openwall.com Subject: Re: Fixing the glibc runtime linker On Thu, Feb 19, 2015 at 10:30 PM, Tim Brown <tmb@...35.com> wrote: > On Friday 20 February 2015 01:38:31 Paul Pluzhnikov wrote: >> FWIW, relative RPATHs are quite fundamental to our test execution >> environment, and any patch that unconditionally ignores them would >> have to be reverted in our tree. > > That's useful to know. Is that for setuid binaries or more generally? We don't build/test setuid binaries, so if you only enforced the restriction for setuid binaries, then we wouldn't have any problem. > As I > noted, it would be dead easy only to use the part of the patch that rejects > them for the former only. Although as I said, that offers less protection. > Would that make the patch more consumable? Yes, that form would work for us. > Another option would be to have > something like /etc/suid-debug which could flag that an override is in > operation. You could also reject relative RPATH for all binaries, unless a specific LD_ALLOW_RELATIVE_RPATH or some such environment variable is set. We could then set that environment variable in the test execution environment, but not outside of it. I guess my point is that we must have the ability to use relative RPATH in testing, so either we'll have to revert your patch, or make an escape hatch of some sort. -- Paul Pluzhnikov
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ