-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'll do a recapitulation of what has been covered thusfar in this message. It's a long one, but it'll get us all on the same channel.
John Richard Moser wrote: | 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. |
Paragraph (2) was not discussed. Coverage of manipulating the gcc specs file and ET_DYN adavtages and disadvantages should be discussed at some point. This was touched on briefly for clarification in: http://lists.debian.org/debian-security/2004/07/msg00177.html But did not pan out.
| 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. |
Paragraph (3) was touched on. The overhead of SSP has not been discussed; but discussion of SSP in general has. See the end of this post for details.
As for overhead, I'll put out that ProPolice/SSP is similar in implementation to Immunix' StackGuard. StackGuard, to my understanding, places the canaries in a slightly different place; but otherwise is the same deal. It should thus have identical or near-identical results in a benchmark.
Immunix did a benchmark, actually: http://immunix.org/StackGuard/performance.html
PIE (Position Independent Executable) is said by some to have some kind of performance hit on x86. I've never noticed it. It's not exactly "essential" for PaX, but it is *HIGHLY* recommended, as it will reduce potential false alarms (which entail PaX randomly killing things for no real reason) and remove the overhead incurred by having ET_EXEC (which need to be mapped at a constant base) executables mapped in a random base (conflicts with previous statement, thus the overhead).
| 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. |
Paragraph (4) was not discussed in great detail; kernel settings still need to be looked over. I am prepared to deliver and discuss these when needed.
| 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. |
Paragraph (5) has been covered. The cost in terms of overhead was discussed in: http://lists.debian.org/debian-security/2004/07/msg00174.html
It was found with weak confidence (i.e. the tests were not exhaustive, 100% reliable distributed benchmarks; but were reasonable) that SEGMEXEC would pose <1% performance overhead on x86-based CPUs. SEGMEXEC does noticably cut the address space in half.
PAGEEXEC is capable of supplying some ambiguous "minimal" overhead; but it is possible for the speed-up that allows for this to be compromised, which falls back to a variable overhead model to prevent a loss of security, leaving us only able to say that PAGEEXEC is "unpredictable."
On HW NX supporting systems (such as AMD64 or PPC), overhead is 0 from PAGEEXEC. The more general overhead from PaX (i.e. the extra kernel code) is just a few extra checks and some randomization, and thus is not at the moment predicted to be significant; at worst it is computationally impossible for it to be greater than the total overhead incurred from SEGMEXEC.
It is important to note that the benching tests were done with full PaX vs PaXless. See the message referenced above for an outline of the test performed.
| 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). |
Paragraph (6) was covered partially in: http://lists.debian.org/debian-security/2004/07/msg00174.html
It is noted that binaries can be marked to control protections of PaX. It is also noted that I can supply a patch to PaX which allows the SEGMEXEC/PAGEEXEC selection on boot-up on the kernel command line, in case the limitations of SEGMEXEC (1.5GiB address space) on 32-bit CPUs gets to be restricting.
It should have been covered that on 32 bit CPUs, if SEGMEXEC becomes restricting, paxctl -Ps or chpax -Ps (depending on if it has PT_PAX_FLAGS in its ELF header or not) can be used to force PAGEEXEC if PAGEEXEC and SEGMEXEC are available, regardless of the default.
I also should have noted by now that the PaX patched kernels can be compiled with PaX disabled, to provide a kernel-image for non-PaX kernels. This would be a last-ditch effort which will work if there is simply no other work-around for a given system; although paxctl/chpax - -psemrx on the offending binaries does basically the same thing for those alone.
Putting PaX in softmode on the kernel command line (pax_softmode=1) is not sufficient, as poorly marked binaries (say -psE, which makes no sense because -E isn't needed without -P or -S) will not be allowed to run by PaX regardless of softmode.
ProPolice/SSP compatibility will need testing on the distribution side. ~ This is fairly simple to deal with: Package breaks, gcc - -fno-stack-protector -fno-stack-protector-all . :) Avoid - -fstack-protector-all unless you REALLY want to deal with things breaking; I've heard that C++ especially dislikes -all, and haven't heard since about it being fixed.
| 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. |
Paragraph (7) is a full explaination: Once the Debian devs have this in place, the users don't need to give a half a damn.
| 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. |
Paragraph (8) hasn't been discussed in technical detail; however, it's sufficient to say that it doesn't really matter if you're willing to take my word on this one. If you're interested, I can show controlled theoretical situations where ProPolice/SSP is evasable.
PaX does not catch buffer overflows directly; thus, any attack stemming from a buffer overflow but not triggering PaX is only going to be caught by SSP.
| 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. |
Below are my final notes in recapitulation.
====1
It is also important for compatibility discussions to discuss the message archived at: http://lists.debian.org/debian-security/2004/07/msg00105.html regarding binutils with PaX and SSP. This is a pretty short topic, which I'll outline here.
It doesn't hurt to have the PaX binutils patch (which supplies the PT_PAX_FLAGS header field) on PaX or non-PaX systems; the kernel will load either type with or without PaX in the kernel. Thus, if Debian is going to supply and support a PaX system with binaries marked as appropriate for PaX, the default binutils should be a PaX patched one.
If Debian is also going to support SSP, then SSP must also be patched in. As I understand it, this will have no effect for binaries compiled - -fno-stack-protector.
Both patches would be included in the default version of binutils in the ideal security situation of PaX+SSP combination.
====2 The issue of 'mudflap' was touched on in: http://lists.debian.org/debian-security/2004/07/msg00175.html It was responded to in: http://lists.debian.org/debian-security/2004/07/msg00180.html This response referenced another message at: http://lists.debian.org/debian-devel/2004/07/msg01154.html This message indicates that mudflap is not suitable as a security tool, because of its excessive performance impact. ProPolice/SSP should be ported to 3.5 when 3.5 is around, and I've heard that nothing in 'mudflap' should really interfere with the smooth operation of SSP.
====3 The issue of trying to patch Debian's kernel-image sources with PaX was discussed in: http://lists.debian.org/debian-security/2004/07/msg00179.html
Note that I am not advocating a "kernel-patch-2.6.7-pax" package; but rather, a modification of the base system and a "kernel-image-2.6.7" with PaX as well as a "kernel-image-2.6.7-nopax" with PaX disabled. My aims are for Debian to supply the most secure base possible without being invasive in terms of overhead, compatibility, or end-user complexity.
I expect you may instead have "kernel-image-2.6.7-pax" with PaX enabled, and "kernel-image-2.6.7" with it disabled, as an introductory test. This is fine; but both may indeed be worked off the same tree, with the PaX patch applied.
| --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
iD8DBQFBBZKuhDd4aOud5P8RAmZEAJ9WIqjuOeRgXPayC/3fCDVOu3v3BACfdcQB 0RT+u2WXMkXK8+XTYPQiFvQ= =Fd7I -----END PGP SIGNATURE-----
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]