opensource.dyc.edu

This is perhaps our tightest release yet. While the kernel remained stable at hardened-2.6.28 (a minor bump from -r7 to -r9), we concentrated further on improving the toolchain. After painstakingly wading through a sea of binaries, figuring out what breaks and what doesn't with various toolchain hardening, we able to apply -fstack-protector-all -D_FORTIFY_SOURCE=2 -fPIC -fPIE to cc1, and -pie, -now, -relro to the linker in producing all of our libraries and binaries. Trouble only came from glibc and evolution.

The glibc problem is a known issue that arises because -fstack-protector-all adds protection to all functions with buffers, irrespective of their size. By contrast, -fstack-protector only adds protection for buffers of 4 bytes or more, and does not cause a problem for glibc. This savings makes sense because addresses are 4 bytes long and so its hard to say what one could do with a two or three byte buffer. Luckily glibc also has -D_FORTIFY_SOURCE=2 which provides some additional buffer protection and enforces some best practices when calling functions --- the sort of programming your professor told you you should practice, but don't anymore because you realize the compiler isn't as strict :) Take a look at the explanation on the Ubuntu page describing their compiler options. There's some other good stuff there too.

The story with evolution is a different one. That code base is plagued with some design issues that hopefully will be resolve with the release of evolution 3. Basically, the complex interlinking between libraries makes it impossible for the linker to apply -z,now which disables the lazy binding of function calls. (Lazy binding = the resolution of symbols at function call time, not at execution startup). Since lazy binding opens up attack vectors where malicious functions could be introduced and linked during execution, we prefer -z,now. So only for evolution did we emerge with LDFLAGS="-Wl,-z,lazy" rather than "-Wl,-z,now,-z,relro". (BTW, if you're wondering what relro does, it makes the relocation table read only in the final ELF, so after binding is done at execution startup by -z,now, there's no possibility of relocating where a function call branches.) You'd think the story ends there, but it turns out that we also had to also use -fstack-protector (not -all) on the amd64 release for evolution because it has a segfault when invoking the Calendar which causes grsec to signal 11 it. Sheesh! For consistency, we compiled it the same way on i686 even though the segfault didn't occur there.

Well the artwork is a little stale --- we'll get to that next time --- but all in all I'm happy with this release. There were very few critical updates, so this was a good time to work on the toolchain :)