[rsbac] Fwd: some PaX Q&A

[Peter Busser]

Hi!

> 2. stability: anything before last december is not comparable in quality
>    to the current patches, so (bad) experiences based on them should be
>    reevaluated before making a decision.

My negative experience is from before December. I have generated 2.4.20
kernel-image packages recently and currently I am testing that version on
several different machines. And so far I am content, no crashes at all.

There are a few issues though. I chose to enable mprotect() restriction and it
seems that libz.so does not like it. Other shared libraries are no problem, but
libz.so causes a call to mprotect() with some _EXEC parameter. I have no clue
where to go looking for the cause of this problem. Any solution, pointer or
clue is appreciated.

And there was some problem with recompiling GLIBC, it would terminate some 
program. However, I disabled trampoline emulation in the kernel configuration
and that might cause this problem.

> 3. recompilation/linking: this is indeed the encouraged way to fully
>    utilize randomization, and since one of the guys seems to be working
>    on a distro (trusted debian if i'm not mistaken), it'd actually be an
>    interesting initiative to begin to provide new make targets for the
>    most affected daemons and produce the ET_DYN ELF executables without
>    further user intervention. for some examples you can take a look at
>    http://www.grsecurity.net/grsec-et_dyn.tar.gz which should give you
>    an idea about the changes needed (normally a few lines of change in
>    the makefiles). also check out et_dyn.zip on the PaX site, it'll be
>    needed to produce position independent executables.

That is what I am currently doing. I have compiled almost all packagages
currently in Trusted Debian using the IBM stack smashing protector (formerly
known as propolice). Now I am trying to get as many packages as possible to
compile with the et_dyn stuff. I placed the .o files included in the
et_dyn.zip file on the PaX site and put them in /usr/lib. And I changed the
GCC spec file and added the names of the libraries to the *startfile
definition, in order to have them automatically added to the link command line
when gcc is called with the -shared flag. This makes it really easy for many
packages.

Unfortunately, this means that some shared libraries are linked with these
object files as well and that will break executables using these libraries. So 
I have to change the GCC spec file regularly. It would be nice to have an
-fet-dyn flag, which would automatically do this. My feeling is that it is
quite easy to do, if you know where to change the GCC source code. I don't, so
it would take me too much time right now.

I haven't been able to do more complicated daemons, like bind and apache. But
I will have a look at the grsec-et_dyn.tar.gz file and see if it can be of
help.

One thing I would like to see is a kind of test suite. Only when you really do
buffer overflows and see them fail, you know that PaX is doing its job well.
This goes for other buffer overflow protection mechanisms as well.

Anyways, PaX is cool! :-)

Groetjes,
Peter Busser