-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm a Gentoo user. I use Hardened Gentoo. I'll spare you my life's story; I believe that a proper PaX enabled kernel with a pie/ssp executable base is appropriate security for a desktop user. The overhead is low, the security gains are high, and it's uninvasive (transparent) to the user. Everything runs under it here, with a small list (see under COMATIBILITY) of relaxed restrictions to apply to executables with chpax/paxctl. As I am not a SuSE user, I do not know if SuSE implements an NX technology. If SuSE does implement PaX, this may prove interesting: The bug ID noted in the COMPATIBILITY section gives a list of all packages that to my knowledge can't be currently built to work 100% guaranteed under PaX. If SuSE currently implements ExecShield, I believe it may be useful to evaluate PaX versus ExecShield. PaX is still under active development, and was originally released in late 2000. It is a fairly mature technology, and provides per-executable security relaxation via elf header markings. Most executables can run under full PaX restrictions without a hitch. For the timebeing, it may be wise to disable the "Disallow ELF Text Relocations" option under Address Space Layout Randomization in PaX; this is extremely restrictive, and will definitely break X with the elfloader. OVERHEAD In my personal experience (kernel compile timing tests), full PaX with SEGMEXEC and ASLR causes a 0.6% performance hit. The pie/ssp stuff seems to give no significant overhead. All in all, this stuff is pretty much sane to have on by default in terms of performance. COMPATIBILITY As for compatibility, much breaks under PaX. This is ok. PaX allows you to mark the headers of binaries to relax restrictions on them; and there's a pretty comprehensive set of markings in Gentoo Bugzilla Bug #40665 at http://bugs.gentoo.org/show_bug.cgi?id=40665 that you can start with. You can have a start-up script to handle this; but it's also interesting to note that because these mark up the header of the binary, you can store pre-marked binaries in the RPM. You'll want to do a few toolchain changes for PaX. http://pax.grsecurity.net/ has patches for binutils that add in the elf header fields for paxctl; you'll want to support both fields in any pax-enabled kernel because binary-only stuff will only support the nonstandard, legacy chpax fields. Paxctl uses fields that are specifically set aside for PaX. ProPolice is a gcc patch that adds stack smash protection via - -fstack-protector. Some things such as mozilla and firefox set this off themselves, so of course don't compile them with this. Most everything else runs fine with it. There are also various things you can do to produce -fPIC -pie by default executables. Lots of things (KDE, Qt) don't like this, so watch what you do. There *is* a pie-by-default patch being worked on by the Hardened Gentoo project; kde ebuilds still use -fno-pic to disable it so that KDE doesn't break. Watch what you do this to. PAX I wrote a wikipedia on PaX. http://en.wikipedia.org/wiki/PaX would be said wikipedia article. PaX basically supplies NX capabality and proper VM policy. ExecShield is similar to PaX; but PaX is from late 2000 and actively maintained still, and thus more mature. It provides mprotect() restrictions and full address space layout randomization, as well as low-overhead noexec pages and policy to prevent PROT_WRITE|PROT_EXEC pages and to prevent !PROT_EXEC pages from getting PROT_EXEC. This basically prevents any sort of code injection. Also, any attacks relying on executing existing code must be able to map out the layout of loaded libraries and the executable base. PROPOLICE http://en.wikipedia.org/wiki/ProPolice This segfaults or exits or somehow kills programs if you write past the end of a stack-allocated array. It costs a few extra instructions and a function call. Gentoo, of course, supplies ProPolice with their gcc ebuild. PIE Position Independent Executable. These executables are just like shared libraries, except they have main(). This allows the executable base to be loaded anywhere in VM space. By doing this, PaX won't have to do odd mappings to map those exceutables randomly into VM space. This saves on overhead. Of course, not all binaries can be made position independent (Closed source stuff, KDE, etc); do your testing. RESULT The result of supplying a PaX kernel with a pie-ssp base is fairly straightforward: Most exploits in software such as the wu-ftp exploit from a few years ago will be made into simple DoS attacks; rather than handing over a root shell, they will just cause the affected task to crash. Interestingly enough, the security advisory on wu-ftp recommended making the stack nonexecutable. This will achieve that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA8Z0jhDd4aOud5P8RApxlAJ9kwqNuVgEiGgEyr7H48j2ac+3I2gCggow8 v3T4MTLbkzl4tQq0Rjm0Kxg= =6Jvu -----END PGP SIGNATURE-----