Re: PaX on Debian
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
. . . .thunderbird is being weird. It's giving me > where >> should be,
and >> wehre > should be. EH.
Andres Salomon wrote:
| On Sun, 25 Jul 2004 12:57:29 -0400, 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.
|
|
|
|
|> 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)
PaX is stable, grsecurity I can't comment on.
I'm only suggesting PaX. PaX is interestingly enough hosted by
grsecurity; PaX' previous hosting cost money.
http://pax.grsecurity.net/
|> 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.
Anything that gives you an executable area existing above data will lose
the PAGEEXEC speedup. This speedup is the same kind of thing Exec
Shield does; except that when data exists in the code segment, it falls
back to old PAGEEXEC rather than becoming executable like Exec Shield does.
On 64 bit (amd64 for example) and other Hardware NX supporting
processors, there will be *no* overhead imposed by PAGEEXEC. :)
|> 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.
I can give a patch that will allow pax_defaultnx={segm|page}exec on the
kernel command line.
Also, paxctl/chpax can mark binaries to disable segmexec/pageexec.
|
|
|
| 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.
|
:) http://en.wikipedia.org/wiki/Stack_smash_protection (same as the
ProPolice article, which is a redirect) shows how this works.
|
|
| 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.
|
|
There will be breakage in places; but I can point out the settings that
cause permenant breakage. All of the other breakage will be solvable
simply by using paxctl/chpax to mark the affected binaries. These can
be distributed marked up properly in their .deb packages.
|
| 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.
|
No real benchmarks. I did a SEGMEXEC test on 2.6 that showed a scalar
0.6% overhead from full PaX (aslr and SEGMEXEC emulation), by compiling
the same kernel twice:
1. Compile a kernel, install it
2. Patch the source tree with PaX, and repete 1
3. `make clean` in the original source tree
4. `make menuconfig` in the original source tree to regenerate
dependency data
5. Reboot into the non-PaX kernel
6. `time -p make all` in the source tree (makes bzImage and modules)
7. Repete steps 3 through 6 with the PaX kernel
8. Divide the time gathered in the PaX kernel test into the time
gathered in the non-pax test (noPaX/PaX) and subtract 1
This gives how much excess overhead is incurred by PaX (the other way
round gives how much overhead is saved by removing PaX).
I recall that my highest difference was the 0.6% (I believe 0.67% was
about it) "Realtime" measurment; the other two (user and system) were
significantly lower in proportional difference.
Thus, I can say with WEAK CONFIDENCE that full PaX with SEGMEXEC based
on a 32 bit Athlon XP supplies about 0.7% (I tend to say 0.6% off the
record) scalar overhead. We'll be safe and call this a <1% scalar
overhead, which assumedly will hold true because it sholud be
significantly higher than the overhead PaX incurs.
I say that 1% is "Significantly higher" assuming that the large number
of operations performed in the course of a kernel compile narrow the
variation down to a very small area, and thus allow me to theoretically
claim high confidence. I claim weak confidence because I don't have a
lot of numbers behind me to back this up.
On amd64, PAGEEXEC won't add the emulation costs. You can assume less
overhead with PAGEEXEC safely; but I will for my own sake assume EQUAL
OR LESS overhead. I may still be wrong, but it should hold true. Do a
test yourself, is all I can suggest.
I can't comment on PowerPC.
|
|
| 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?
|
|
Of course. Check Gentoo Bug #40665 at
http://bugs.gentoo.org/show_bug.cgi?id=40665 for the init.d script that
is used in Gentoo to mark up binaries for PaX compatibility. There is
an attachment titled conf.d/chpax that is updated when I or someone else
finds an app that breaks and brings the fixes. This list is currently
spawned from experiences on x86 CPUs and does not reflect other
architectures. Do your own tests before committing your work.
Of all apps that are known to break, 100% are fixable thusfar. The
current list at the time of this writing is
http://bugs.gentoo.org/attachment.cgi?id=35971&action=view in the form
of a configuration file to the chpax init.d script.
In the worst case, PaX can usually be fully disabled for a binary via
paxctl -pemrxs or chpax -pemrxs. Only paxctl should be relied on; but
binary-only packages such as Yahoo Messenger or Java may come in a form
without the new PT_PAX_FLAGS ELF header fields. In these cases, you'll
need to fall back to chpax and the EI_PAX, which is both depricated and
non-integral (i.e. strip will zero EI_PAX out on some systems or such,
removing the markings).
| 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.
|
Alright, you win. Third party .deb packages will indeed come unmarked.
~ Of course, once the vendor realizes you're using PaX in your default
base system, he may or may not begin marking these. Also, you could
feed dpkg a bit of a clue about known 3rd party apps that need markings,
if it really becomes a problem.
Very little breaks, but it's entirely possible that 3rd party packages
will fall into that category.
|
|
| 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.
|
|
Just imagine if we had Sasser to deal with -.- "numerous" would be
quite high.
|
| 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.
|
- --
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
iD8DBQFBBEcThDd4aOud5P8RAop8AJwKjqtWEHwxEYhyMt5+kEognqQPwQCcDmwM
Wbm/cpCwQV934i8d6hdoj8o=
=aRcW
-----END PGP SIGNATURE-----
Reply to: