No, I am not toggling mprotect. I am sorry if I was not clear with my questions. It is always off in the examples I am referring to. I probably should've never brought mprotect up because it does not pertain to this discussion. I have been using similar patches to the kernel since the 2.0.x series, and many servers I've built and admin are full on hardened setups (but no X and no Quake3 allowed). Now I am tackling attempting full hardened, rather than partial, on the desktop/workstation.
mprotect->off, SEGMEXEC->on and/or PAGEEXEC->on = crash mprotect->off, SEGMEXEC->off and PAGEEXEC->off = ok The issue is PaX SEGMEXEC/PAGEEXEC is duplicated by the SSP/ProPolice patches to GCC. PaX SEGMEXEC/PAGEEXEC can be easily disabled. SSP/ProPolice cannot be easily disabled that I am aware of. My question is, if you have a program that breaks with PaX's SEGMEXEC/PAGEEXEC, then it should break, too, under SSP/ProPolice, correct? So if I have a program that breaks with SEGMEXEC/PAGEEXEC and I'm using a full-on hardened setup with SSP/ProPolice, I could disable PaX's SEGMEXEC/PAGEEXEC for that program, but it would still break because then SSP/ProPolice would catch and kill it, correct? Thank you for your help. On Saturday, January 27, 2007 20:32, John Schember wrote: > 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
