On Tue, 4 Nov 2003, Peter Busser wrote: > > the reply below is mostly a re-send of a mail i sent to you privately > > but you repeat this argument again without any apparent answer to my > > counter-arguments. > > I already suggested you to reread the PaX documentation, there are the > answers to your questions. There is no need to copy/paste it here.
yes, i've read them, and they do not answer my questions. The PaX documentation says: Non-executable pages and mprotect() restrictions are effective in preventing the introduction of new executable code into an attacked task's address space. There remain only two venues for this kind of attack: [ write files ] [ map existing library ] this is plainly not true. Firstly, PaX doesnt solve the "write a file and mmap() it" problem, so what's your point? Secondly, you can eg. write a shell-script into non-executable memory and system() it. Etc., etc. The ability to mprotect() a page already requires good control over the binary, at which point you can do basically whatever the application can do normally. Arguing for this mprotect() restriction is like arguing that "i am only a little bit pregnant". The attacker controls the application and there are many ways to use that control to do Bad Stuff. The mprotect() restriction is an after-the-fact restriction that reduces system utility in a way that by its own documentation is an admittedly non-complete protection. In fact it adds little if any protection. Exec-shield does not include such arbitrary policy decisions. The attacker has broken in, he controls the app, it's just a matter of time until he owns everything the app owns (or more) - mprotect() restrictions or not. besides, the mprotect() change: Restrict mprotect() CONFIG_PAX_MPROTECT Enabling this option will prevent programs from - changing the executable status of memory pages that were not originally created as executable, - making read-only executable pages writable again, - creating executable pages from anonymous memory. breaks a fair number of legitimate applications, breaking binary compatibility, which is an additional no-no too. and this is easy. Breaking binaries and increasing security by making the system less useful. > > Summary: i can see no significant differences between the paxtest output - > > all the differences seem to be bogus, see the details below. > > Fact is: There is a difference in paxtest output between PaX and > exec-shield. And it is not a difference in exec-shield's advantage. this what i'm disputing, because those tests i criticised are arbitrary (see above). The other tests are OK and paxtest is a useful utility, no doubt about that! by your argument you could add this to paxtest: printf("PaX is inherently better\n"); there's no way exec-shield could get around this "difference in output" ;-) > Another fact: If you don't like this difference, you can change the PaX > kernel configuration to lower the level of security to the same level as > exec-shield. my point is that CONFIG_PAX_MPROTECT is not acceptable in a generic Linux kernel, and that there's no 'reduction in security' by not using it. If you can give me specific examples of exploit techniques that this disables in a way that cannot be worked around then my point is incorrect. Ingo