robert at linuxfromscratch.org
Tue Nov 28 11:58:55 PST 2006
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the hlfs-dev