Re: PaX on Debian
On Sun, 25 Jul 2004 12:57:29 -0400, John Richard Moser wrote:
> -----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.
>
I think debian-kernel would be a better place to discuss this (at least,
the PAX stuff). I have used PAX/grsec for a while now, on 2.4, and have
been very pleased with it. I would love to be able to include it in
debian 2.6 kernels, but we need to make sure that:
a) it's stable (currently, we have a glibc bug that breaks PAX; #245563.
I've also heard reports of various grsec problems on 2.6; I don't know how
many of those are PAX issues)
b) it doesn't introduce significant overhead (we need *real*, up-to-date
benchmarks here); i'm told that there have been optimizations to PAGEEXEC
that make it comparable in speed to SEGMEXEC, but I haven't tried it.
c) it doesn't introduce limitations (SEGMEXEC isn't an option, for
example, since it splits the process address space in half, and can't be
turned off to reclaim address space) that aren't easily disabled.
> 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.
>
I haven't tried SSP yet, but I've heard good things about it. I'll have
to do research on it when I have more free time.
> 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.
>
Yes. We cannot have major regressions in the kernel, with the
introduction of something like this.
> 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.
>
Do you have any real benchmarks showing exactly how much overheard is
added on common hardware (i386, powerpc, and amd64)? I'm merely
interested in 2.6.
> 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).
In terms of the packages that are known to break, how many of them are
fixable? Do you have a list of the packages that break?
>
> 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
I disagree with that; we don't know how many 3rd-party binary apps PAX
will kill. However, I'm not overly concerned with that right now, as it's
the sort of thing that we won't be able to measure without actually having
people using PAX.
> 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
Agreed. I've seen PAX/grsec stop numerous attacks on our boxes.
> 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-----
Reply to: