[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[suse-security] Secure Base with PaX, ProPolice, and pie
-----BEGIN PGP SIGNED MESSAGE-----
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
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.
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.
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.
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.
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
Of course, not all binaries can be made position independent (Closed
source stuff, KDE, etc); do your testing.
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
-----END PGP SIGNATURE-----
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here