On Sunday 29 May 2011 01:13:48 Rogelio Serrano wrote: > On Sun, May 29, 2011 at 12:29 PM, Robert Connolly > > <rob...@linuxfromscratch.org> wrote: > > Hi. > > > > I'm not sure if I understand the question. > > > > Libc can not build with -fstack-protector-all or -D_FORITTY_SOUCE=2 > > unless their functions are moved to the linker library ld.so. This is > > not practical with the fortify_source functions, but it is possible for > > -fstack-protector (ssp). In both cases, the Glibc developers do not want > > to do this. See: > > > > http://sourceware.org/bugzilla/show_bug.cgi?id=7065 > > > > The technical issue is that library functions get moved to the linker > > library, because it causes a reverse dependency within libc. This is > > very unorthodox, and the Glibc team is not motivated to do it. > > > > In HLFS the Glibc _programs_ are hardened with SSP and _FORTIFY_SOURCE, > > because this is possible without major modification to Glibc, but not the > > libraries. > > > > Simply put, libc itself will not build with hardening options. > > > > I'm not prepared to adopt modifications that would allow it just for the > > sake of hardening the C library, because there is a risk of > > destabilizing the C library. It's too complicated for little benefit, > > unless of course the Glibc maintainers add support for this. > > > > robert > > so whats the implication of this? we check all data before we pass > them to libc functions? i understand that this makes it hard to > protect against heap overflow bugs but those are very hard exploit. is > that right? > > i wonder how other security oriented os harden their libc.
I don't think anyone hardens libc with GCC options. They just write the code carefully. HLFS is the only one I know of that hardens the libc programs. robert
signature.asc
Description: This is a digitally signed message part.
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
