Your getting two different things confused here. Mprotect restrictions via PAX and SSP enabled in the tool chain preform different functions and do not interfere with one another. Nor do they prevent the other from working correctly.
http://pax.grsecurity.net/docs/mprotect.txt "The goal of MPROTECT is to help prevent the introduction of new executable code into the task's address space." http://www.trl.ibm.com/projects/security/ssp/ "The protection is realized by buffer overflow detection and the variable reordering feature to avoid the corruption of pointers." Basically PAX's mprotect restrictions disallow creating executable anonymous mappings, creating executable/writable mappings, making executable/read-only mappings writable, and making non-executable mappings executable. SSP introduced variable reordering and placing pointers before buffers to prevent corruption of memory via a stack smashing attack. SSP's changes should not effect the overall functioning of an application unless it does something strange like use a stack smashing attack on itself. Using SSP will not prevent you from utilizing paxctl to exempt specific executables from mprotect restrictions. John Schember On Sat, 2007-01-27 at 19:40 -0800, [EMAIL PROTECTED] wrote: > If I paxctl -PS the ioquake3 binary it crashes on startup with the error: > > PAX: execution attempt in: /dev/zero > > logged to the syslog. If I paxctl -ps ioquake3 it runs fine. Of course > mprotect is disabled in both cases. Quake3 is really only an example though. > > I guess my larger question is: > > If I use the SSP-enabled toolchain, I'll loose my ability to toggle this > protection off and on at will right? Am I correct that the only work arounds > in this case would involve some kind of recompiling with per-package flags, > etc.? > > Thank you for your help. > > On Saturday, January 27, 2007 18:59, John Schember wrote: > > SSP is stack smashing protection. Unless an application your using for > > some strange reason likes to over run the stack and execute code just > > like a buffer overrun attack you won't have a problem. As far as Quake3 > > goes you won't have a problem with the hardened tool chain. > > > > John Schember > > > > > > On Sat, 2007-01-27 at 18:20 -0800, [EMAIL PROTECTED] > > > > wrote: > > > I've had a "partially-hardened" workstation for awhile now. I use > > > hardened-sources and enable many of the PaX/grsecurity options including > > > stack smashing protection. This works great as I can disable SEGMEXEC, > > > PAGEEXEC and mprotect for Quake3 (ioquake3) and get it to run. My > > > question is if I take my workstation to a full hardened system with > > > SSP+PIE toolchain, etc. will I still be able to run Quake3 and other > > > programs like it? If I went to a full Hardened Gentoo system, even if I > > > disabled PaX's SEGMEXEC, PAGEXEC and mprotect, which is sufficient to run > > > Quake3 now, the toolchains' own SSP would then kick in and stop me, > > > right? > > > > > > I'm normally a test and do-it-myself kind of person, but I really don't > > > want to have to recompile the system to find out and then recompile again > > > if gcc's SSP/ProPolice does stop me. > > > > > > Side note: I masked gcc-4* and >=glibc-2.4 when they were stabled in x86. > > > I still run gcc-3.4.6-r2 and glibc-2.3.6-r5 so switching to the hardened > > > profile will not present any of those types of problems for me. > > > > > > Thank you for your help. -- [email protected] mailing list
