On Tuesday 28 November 2006 13:55, Robert Baker wrote: > No ssp will require the removal of the regex_ssp patch in the perl > section of the book.
I noticed the regex_ssp patch for Perl wasn't needed anymore. I think it has something to do with the way SSP was modified when integrated in glibc-2.4 and gcc-4.1, compared to IBM's version. > My question is if we intend not to use ssp in the > 2.4 branch doesn't that compromise the level of security offered by this > kind of system? I realize that adding features to GCC can introduce > issues in and of itself, but stack smashing is one of the most common > attacks used today... Obviously if the patch affects the stability of > the system then we are not there yet. The glibc-2.4/2.5 SSP library is not compatable with the SSP patch for gcc-3.4 from IBM. I didn't look into back porting gcc-4.1's ssp to gcc-3.4 because I suspect it's not straight foreward. I also noticed no one else backported it either, like Debian or Gentoo. An alternative is replacing glibc-2.4/2.5's SSP library with the one used in glibc-2.3.6, but it makes me wonder why does it break Perl's regex. And another alternative is to use IBM's SSP with libssp.so (there are patches for this), but again makes me wonder why it breaks Perl's regex. With all the Grsecurity/PaX options enabled in the kernel, the only exploit not detected by Grsec, which is detected by SSP, is "return2libc". While this is fairly serious I don't think its practical to add SSP to a gcc-3.4 toolchain, for a release which is expected to be rock-solid. I've considered the alternative of using gcc-4.1.1 without mudflap and fortify_source to get SSP into the 2.4-branch, but gcc-4.1.1 can't build a linux-2.4 kernel, and can't build gcc-2.95.3, without tons of patches which would destabilize gcc-2.95.3. There are unfortunate compromises when making a stable release, and I think this is one of them. I hope to make up for this by using sound code in the base system, audited by the stricter gcc-4.1.1 (or even gcc-4.2) compiler warnings in unstable and merge the differences to the stable packages. > I have been running thru what we have thus far. In pass 2 of gcc I found > I had to use --with-dynamic-linker= just to get the linker tests to > pass after a gcc install. I removed the specs_x86 patch all together. It only worked on i386, and it was screwing up Binutils' tests because Binutils detects the default dynamic from parsing 'gcc --help --verbose', which produces the ./configure command used to build GCC (like from gcc -v), and 'ld-*.so' matches twice and makes a mess of the '-dynamic-linker' option used in Binutils tests. Since that patch only worked for i386 its just as well to use an Sed command to prepend /tools to the dynamic linker name when building GCC, and this will work fine with uClibc too (with xml conditions). I preferred that patch with the idea of having read-only sources, but its not a big deal. robert
pgpL89aVmHWjG.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
