PaX on Debian
-----BEGIN PGP SIGNED MESSAGE-----
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
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
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.
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
-----END PGP SIGNATURE-----