I'm confused as to how prelink and ExecShield interact, and
unfortunately, neither of these two docs really clarifies the issue:
http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf
http://people.redhat.com/drepper/nonselsec.pdf
The nonselsec.pdf document states that prelinking and load address
randomization exclude each other. Prelink does not appear to conflict
with either randomizing the stack location or making the stack
non-executable.
But if that's the case, then what exactly does the --no-exec-shield
option to prelink actually *do*? What functionality of ExecShield
(that it doesn't already conflict with) is left for it to disable?
The reason I'm curious is due to dealing with programs that load
Windows DLLs and want to load them at specific addresses. Here's what
mplayer recommends as a work-around:
http://www.mplayerhq.hu/DOCS/HTML/en/faq.html#id2895374
If I compare prelink.log files with and without the --no-exec-shield
option, it's obvious that --no-exec-shield does in fact free up
address 0x400000:
--- prelink.log.old 2004-10-15 04:03:35.000000000 -0400
+++ prelink.log 2004-10-15 17:38:15.549151696 -0400
@@ -1 +1 @@
-/usr/sbin/prelink -av -mR -q
+/usr/sbin/prelink -av -mR --no-exec-shield -q
@@ -12,2 +12,2 @@
-Laying out 1 libraries in virtual address space 00101000-50000000
-Random base 0x3d5ee000
+Laying out 663 libraries in virtual address space 41000000-50000000
+Random base 0x4d93c000
But I still don't understand why --no-exec-shield has that effect, or
what I actually loose by using it.
The nonselsec.pdf document also states that PIEs are excluded from
prelinking. That makes sense. But if code segments aren't writable
(and I don't believe they are, IIRC), what benefit does PIE actually
bring? Is it trying to make it harder for an attacker to leverage
pre-existing code in the application to launch an exploit?
TIA for any insight...
