Re: PaX on Debian (Demo setup)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've got a chunk of data that can be used for a demo setup over here. I
would like the help of any debian developers that would like to package
up a set of kernels and the scripts that come with this and place them
in a mini-repository, to give the devs a chance to decide if they want
to move PaX support into post-Sarge SID.
Note that this is only a skeletal demonstration. A few packages, most
notably X, break because of PaX; this demo marks up these packages so
that they do not break. The most notable effect will be that an
unmarked X will refuse to start when running a PaX kernel, while a
marked one will start fine.
Markings must be applied while the programs aren't in use (i.e. turn off
X before marking it; it'll turn itself off if you're in the PaX kernel :P).
It contains:
~ - PaX kernel patch for 2.6.7
~ - Patch on top of PaX which allows pax_default_nx= on kernel command
line, as well as /proc/pax_status
~ - A pax-flags script that uses /etc/pax.conf to mark up binaries
~ - An /etc/pax.conf
~ - A config-2.6.7-1-k7-pax configuration file for
kernel-sources-2.6.7-1-k7 with the above patches
The two patches patch cleanly to kernel-sources-2.6.7-1, a bit of fuzz
but no misses.
The pax-flags script and pax.conf are modified versions of the Gentoo
script and configuration from Gentoo Linux. They're ugly, but they work
well enough for a demonstration.
The config file is for k7, but the PaX section can be duplicated into
other config files. Note that until glibc is fixed as per bug #245563,
PAGEEXEC can NOT be enabled on x86, as it forces the vsyscall page to be
disabled.
SEGMEXEC is fine for a demonstration. Once #245563 is fixed, PAGEEXEC
and SEGMEXEC can be fixed, with default to PAGEEXEC (except for k6-2),
adjustable via pax_default_nx={page|segm}exec on the command line.
Please read this IRC conversation:
<bluefoxicy> pipacs: how hard would it be to add PT_PAX_FLAGS to an
existing binary?
<pipacs> it depends on what you've got in the ELF already
<pipacs> if you have a program header that you can 'recycle' then it's
trivial
<pipacs> prime candidate these days is PT_GNU_STACK ;)
<bluefoxicy> otherwise it's not so easy?
<pipacs> otherwise it's some real hacking on it, to extend the first
PT_LOAD segment downwards
<pipacs> that will force you to adjust all file offsets
<pipacs> that's some work
<bluefoxicy> pipacs: the #debian folk don't seem to like the idea of
distributing binaries with PT_PAX_FLAGS, and were arguing that it
"should be easy to have a tool that just adds the field"
<bluefoxicy> and i'm like ". . . there'd already be one if it was that
easy. . . ."
<pipacs> it's normally not 'cos the program header table is not easily
extensible
<pipacs> 'cos there's no room in the file normally
<bluefoxicy> heh
<bluefoxicy> can I quote you on that some time later?
<pipacs> sure but i dunno what that helps
<pipacs> on one hand, presence of PT_PAX_FLAGS doesn't cause any trouble
<bluefoxicy> pipacs: it helps me convince the debian devs to use a
patched binutils to build the system
<pipacs> on the other hand it's useful only under pax kernels
<bluefoxicy> yeah but it's not damaging under non-pax kernels, and
non-trivial to add later
<pipacs> so debian should first decide if they're interested in pax at all
<pipacs> well, debian is or will soon be using gcc 3.x
<bluefoxicy> I'm trying to get them interested in it (mandrake and suse
just ignored me), hence all the mailing list conversations.
<pipacs> that and a recent binutils will produce PT_GNU_STACK
<pipacs> so we can always reuse that
<pipacs> it's useless anyway under pax
<pipacs> i'll add support for such a conversion to paxctl
If Debian is interested in PaX, they should use PT_PAX_FLAGS. This will
soon be possible by junking PT_GNU_STACK for PT_PAX_FLAGS via paxctl;
however, it is also possible to add the field by using a patched binutils.
Also, supporting PaX, although easy to demonstrate in a non-invasive
way, is a *VERY* invasive task distribution side. Everything that can
be compiled ET_DYN (-fPIC -pie) should be; ideally, everything (except
certain programs like wine, which needs the wine preloader to load the
executable at a predetermined base) would be position independent.
Notice below:
bluefox@icebox /data % file /bin/cat
/bin/cat: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
stripped
Once such support is figured out, it will be trivial for Debian's
developers to maintain the distribution (about as trivial as is now,
with the occasional bump when something suddenly doesn't want to compile
ET_DYN or needs to be marked up). Thus, although it is invasive at the
start, it is fairly non-invasive to the continued maintainance process.
Debian should also decide if it will support an SSP base; the problem of
pie/ssp should be tackled in one sweep, since they're easy to identify:
~ pie problems will cause programs to fail to compile (cannot find
available register of class "BREG" or such); SSP problems will cause
programs to crash. In the case of SSP, the crash is an indication of
either A) an attack (an exploitable bug being exploited), or B) a bug
(not necessarily exploitable).
The technology known as "mudflap," according to information I've
gathered so far, is not a suitable replacement for SSP; mudflap
generates prohibative overhead, while SSP generates trivial overhead.
- --
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
iD8DBQFBCFaOhDd4aOud5P8RAnOYAKCAix+b0icl3tu6Y+/1aBZRkn6dUACfewj3
KwT0sh2DBRZQ/zjnOV7z+pE=
=0G6T
-----END PGP SIGNATURE-----
Reply to: