-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm interested in discussing the viability of PaX on Debian. I'd like to discuss the changes to the base system that would be made, the costs in terms of overhead and compatibility, the gains in terms of security, and the mutability (elimination) of the costs.
A PaX protected base system would be best compiled ET_DYN, which can be done by using modified spec files or a specially patched gcc to make pies-by-default binaries. Certain things don't compile this way; and thus would need this functionality disabled (modified spec, -fno-pic - -nopie). This will be discussed in greater detail later.
A PaX protected base would also benefit from Stack Smash Protection, which can be done via the gcc patch ProPolice. This imposes minimal overhead, which will be discussed in greater detail later. It overlaps and extends many of the protections PaX offers, but catches earlier on; and is thus a good system to pair with PaX.
PaX is a kernel level patch, so certain kernel settings would be needed. ~ Some of the settings available in PaX are high-overhead or break things in a way which cannot be worked around, and should thus be off. These will be discussed later.
The costs in terms of overhead of PaX (on legacy x86 systems where it must emulate an NX bit) and ProPolice are both very minimal. With PAGEEXEC on hardware NX supported systems such as AMD64, there is no measurable overhead from PaX. ProPolice brings no significant overhead; measurements taken for StackGuard (a similar system which puts the canaries in a different place, but is otherwise identical) are available for this. This will be discussed in detail later.
The costs in terms of compatibility with PaX and ProPolice are also minimal, and mutable. PaX breaks a handful of packages; but all of these can easily be marked via the chpax and/or paxctl tools to disable the protections that break them. ProPolice is set off by some programs (firefox for one), which simply must be compiled without ProPolice (-fno-stack-protector -fno-stack-protector-all).
Neither of these systems delivers a cost in terms of complexity of use to the user; these are both 100% transparent to the user. Added complexity in the form of configuring the PaX kernel; setting up the binary markings for packages that break; and disabling the gcc modifications for things that break are taken up by the distribution.
Both of these systems bring a significant security gain. ProPolice prevents buffer overflow attacks, turning them into program crashes (DoS attacks). Some buffer overflows, especially for buffers in structures adjacent to function pointers or other pointers, can escape the ProPolice logic, however; thus PaX is also needed. This will be explained in greater detail later.
A wikipedia article exists on PAX at http://en.wikipedia.org/wiki/PaX and makes a good read for this. Likewise, one for Stack Smash Protection at http://en.wikipedia.org/wiki/ProPolice would be ideal to look over.
Please reply and cite specific concepts you would like to discuss further. I would rather not write up a 10 page paper by explaining all of these at once; but if demanded, I'll do just that. Be ready to swallow a large pill though.
- --John
- -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBA+Z4hDd4aOud5P8RAqTjAJ45bMPCCW04EeDjX+NZP9m3UmC3rgCfSzt2 78Qydi7ZCMdO6vdRXuH/ZMw= =2QiO -----END PGP SIGNATURE-----
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
