On Sat, Oct 09, 2004 at 05:10:49PM +0900, aq wrote: > - What exactly are the changes of exec-shield since the first > announcement? (the ANNOUNCE-exec-shield file I mentioned above says > that exec-shield has significant change, but then refered to the > discussions on the (vanished) mailing list !) some refinements mostly; I'm not sure if randomisation was part of the initial change but we do that of everything now; PIE got added since then. Also the execshield project has resulted in glibc level changes as well (as per Ulrich's paper) > - What are the pros/cons of the changes? more security; we keep looking at ways to make exploits harder and if we find ways that can be done relatively unintrusive to correct applications, we will incorporate those. > - PaX also features the no-executable memory technique (besides other > things), so what are the pros/cons of exec-shield to PaX? PaX and Execshield in part overlap. The biggest difference is in the balance of compatibily versus security features. Exec-Shield is has the design goal to give maximum protection possible within strict compatibility limits (and thus allowing it to be enabled in a general purpose distribution like Fedora and RHEL), while PaX gives some more protection but does sacrifice compatibility somewhat. (for example by halving address space, and by blocking apps requesting executable mmaps) The result is that execshield is less finegrained in it's protection than PaX (assuming you don't have a cpu with NX capabilities). Execshield allows applications like the X server to make memory executable if the app explicitly asks for it. The famous paxtest version that tries to show that an application can disable execshield is proof of this, an application can do an mprotect/mmap some stack memory as executable and with that, disable the execshield protection effectively. Just about no application actually does that though. This same "stack can be made executable" holds for apps that use C language constructions that need executable stack, or are in programming languages that require the same. PaX will by default block those (and thus prevent the app from working unless you mark it), while Exec-Shield will allow them to run, but obviously without stack protection. I'm not casting judgement about which is better. I suspect the answer very well might be different for everyone since everyone will have different security requirements. Exec-Shield covers a wide range of the actual protection PaX does too, it's up to you if you consider the last bit of security important enough to give some of the compatibility up. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
