On Tue, Jan 24, 2012 at 2:43 AM, Radoslaw Szkodzinski <[email protected]> wrote: > Hello, > Please don't forget to CC me, as I'm not yet subscribed to the list. > (will rectify it soon, once I improve my mail filter) > > As it has come to my attention, Sabayon doesn't build its software > with either PIE or stack protector. > This is quite suprising, as even major distributions like Fedora or > Ubuntu enable at least partial SSP. > > In Gentoo, this is essentially trivial, by just enabling USE=hardened > and rebuilding gcc. This will add CFLAGS="-fstack-protector-all -fPIE > -D_FORTIFY_SOURCE=2" and LDFLAGS="-Wl,-z,now" > to everything the default compiler builds. This can be temporarily > disabled using eselect gcc and picking one of the options, or > filtering flags in an ebuild. > > Additional assembly-bearing packages such as mplayer can have it also > hardened (for PIE) with USE=pic, but this might come at an important > performance cost. > My own tests with Mesa shown a 25% performance drop in gallium from > USE=pic. This is probably not worth it for a desktop distribution and > affects only a score of packages. > > On x86-64, Position Independent Executables (PIE) comes with no > performance cost, while on x86 it costs as much as > -fno-omit-frame-pointer. (below 10%) > This feature has to be combined with Address Space Layer Randomization (ASLR). > Linux kernel since 2.6.25 contains Exec Shield, which is such an > implementation. Not as strong as grsecurity PaX, but still quite > decent and making life far harder for hackers. > > PIE protects against local exploits, but using it completely > effectively requires an additional tiny kernel tuneup, such as > disabling /proc/self/maps (trivial patch, also part of grsecurity) > or preventing access to it with an ACL, such as Tomoyo, SELinux (both > mainline) or grsecurity (patch). > Once you have that done, the only remaining attack is trying to damage > the random number generator, which is hard on Linux. > > Stack Protector is another tool almost completely (see above caveat) > preventing attacks against automatically allocated variables. > This means that even if code allows an overflow, the compiler will > check the access after the write. Improves strength against a class of > both local and remote exploits. > Stack Protector support can also be enabled for kernel code with a > kernel config flag. (since 2.6.32 I think) > > Of course, this is not end-all-be-all. Both of these techniques > necessitate good logging of crashes to avoid brute forcing. > To that end, kernel auditing subsystem can be used (with auditd) or > grsecurity patchset - and a bunch of simple scripts to kill any > session that's misbehaving and e.g. stop cron from restarting > services. > Tools such as Nagios can provide constant monitoring. None of it > matters for services that don't automatically restart, but stopping > the local sessions that crash can well still be useful against > bruteforcing local exploits. > > Bottom line: it's not foolproof, but it's cheap and quite effective > regardless. > > USE=hardened also enables 2 linker flags: > -Wl,-z,relro - makes text relocations (if any) read only - this is > default in binutils since at least 2.20 > and > -Wl,-z,now - forces all dynamic libraries to be linked in at the start > of the executable, which prevents .so switching attacks on long > running daemons. > This might cost some in memory and load time for applications with > lots of .so linked in, but is usually unnoticeable. > > Another enabled CFLAGS is a special glibc flag, -D_FORTIFY_SOURCE=2. > This feature will cause simple memory errors and bad practices to be > caught at build time, as well as enable checked malloc. > Cost of the feature is very low as opposed to hard randomization like > in libmudflap. > Quite a few distributions use it to catch bad code in many packages. > Gentoo contains some fix patches that haven't yet been sent upstream > as well. > > Here's some general writeup: > https://wiki.ubuntu.com/ToolChain/CompilerFlags > Note: while Ubuntu applies SSP to smaller stack variables than > default, they don't enable it for all. Not sure why. > > Another writeup by flameeyes goes here: (with a minor mistake about > ASLR availability) > http://blog.flameeyes.eu/2009/11/02/the-pie-is-not-exactly-a-lie > > -- > Radosław Szkodziński > >
Thanks for the input. Look for Sabayon to begin working in more hardened features. We plan to do this incrementally to minimize the possibility of unintended consequences. :)
