toolchain stuff (and libsafe)
robert at linuxfromscratch.org
Thu May 31 11:33:52 PDT 2007
I got Glibc building protected programs using only the configparms file, and
no patches (except the -fno-stack-protector Sed command for ./configure). I
didn't try the test suite yet. There is one minor ugliness... when building
the library half of Glibc in nscd/, _FORTIFY_SOURCE is redefined from what is
in configparms to what nscd/Makefile sets. This causes about a dozen
warnings, but is otherwise harmless.
All the 'ignoring return value' warnings from Binutils have been fixed in
Binutils CVS, and I added a patch for that. None of the warnings for GCC have
been fixed upstream. I also backported the patch for -Wno-overlength-strings
to get rid of the "string length `WHATEVER' is greater than the length `509'"
warnings in fixincludes/. I made a patch for the GCC warnings, but I need to
make sure a kernel can be built with it. The patch uses simple if's instead
of assert. It shouldn't be long before binutils and gcc can build
with --enable-werror-always again.
I would like to add either LibsafePlus or Libsafe to chapter 6. LibsafePlus
does a better job than Libsafe, by using another utility called TIED to
reconstruct programs and libraries to emit buffer size information for the
LibsafePlus library. The library checks data size verses buffer size before
filling the buffer, to be sure there is enough room for the data, and exit's
the program otherwise. It does not protect all function, just the more
dangerous ones. For performance both LibsafePlus and Libsafe support an
option, set in /etc/libsafe.exclude, where only processes with a userid lower
than 100 (or whatever) will be protected.
The LibsafePlus/TIED package is fairly intrusive to implement. Each program
and library needs to be reconstructed. Without doing this LibsafePlus will
behave exactly like Libsafe. The major difference between LibsafePlus and
Libsafe is that LibsafePlus's checking is much more precise. The runtime
performance is almost the same.
In theory the _FORTIFY_SOURCE checking is supposed to do the same thing as
Libsafe, but it doesn't. _FORTIFY_SOURCE was designed to sacrifice some
checking for performance. In the Libsafe/LibsafePlus exploits/ directory
there is a 'canary-exploit' printf overflow which is _not_ killed by ssp or
fortify_source. I'm running a lightly configured grsecurity kernel, and it's
not killed by PaX either.
LibsafePlus can also be installed in chapter 7 because it modifies binaries,
and the library is preloaded. Installing it in chapter 6 will detect problems
earlier, but will make the builds in chapter 6 slower. It is fairly
configurable, in that we can choose which programs and user-ids get
protection, and which programs get full (TIED) protection.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the hlfs-dev