[rsbac] some PaX Q&A

[pageexec at freemail.hu]

foreword: i really don't want to turn your list into a PaX support
forum ;-), but since some of you might be interested in trying it
out and would run into similar issues, i decided to CC the list this
time, i hope it's ok.

> 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.

i've quickly grepped through the source of 1.1.4 and there is no
sign of mprotect() or PROT_EXEC in there. how did you determine that
the problem came from zlib? could it be something else instead? if
you load the failing application into gdb and break on mprotect()
you can examine the stack backtrace and see where it came from. in
any case, if it turns out that a given app does need PROT_EXEC
(and cannot easily be rewritten), then you can use 'chpax -m'
to disable MPROTECT on it.

> 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.

i recall that iconv* or something like that needed the gcc trampoline
support which is better not enabled in the kernel at all, so the best
solution is to 'chpax -sp' it (i don't know if it's built along with
glibc, in that case the glibc makefile has to be modified to do it).

by the way, you can know precisely what was terminated by PaX as there
is a KERN_ERR level log event each time it happens, you can grep for
'PAX' in the log file where such events go. it would also help decide
why the app was terminated as there is a small dump of the code that
was going to be executed from a non-exec region (not to mention the
coredump if the resource limits allow it to be generated).

> 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.

yes, that's the reason why i didn't encourage changing the specs file,
or at least not without changing gcc itself as well (such as a new
command line switch). but even then you wouldn't gain much because
the per package makefiles would still have to be modified to make use
of the new switch (i don't think you could make the ET_DYN executable
generation the default, it would be contested by many users and never
make it into the main gcc/binutils trees). i'm afraid that there is no
simple solution, you will end up modifying either the makefiles or the
toolchain.

> 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.

there is one in the making, it's just that the one i've been using
so far cannot be made public (it's not my work and is too old now,
so it misses a lot of situations) and the new one takes time (there're
lots of cases that have to be tested, consider the various PaX flags
(both in the kernel and per app) vs. writable memory regions).