On Tue, Nov 04, 2003 at 06:49:58PM +0100, Ingo Molnar wrote: > > On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote: > > > [...] Are you so certain that Exec-shield stops execution in shared > > library bss/data? [...] > > no, it doesnt, this is the main (and pretty much only) substantial > difference between exec-shield and PaX.
Well that sounds quite a bit different than what you had to say about these yesterday: "these are caught by exec-shield too, and are quite important categories to catch." Clearly both cannot be correct at the same time. > Exec-shield will stop execution in > ET_EXEC binary's bss/data but it will not stop code injection into library > bss/data. Here is the 'protection matrix' of all the overflowable and > shellcodable virtual memory areas: > That's not quite correct. Exec-shield "can" stop, but "will" stop is a completely different matter. I'll let the bugfixed paxtest tell this story, however. > If you mean exec-shield=2 then it is 'forcing' exec-shield and is only > recommended for testing purposes. For the benefit of the readers that might have missed this subtle attempt at diverting the main point of my argument: exec-shield=2 means enabling exec-shield on all binaries but the ones it is disabled for. This would be a secure-by-default design, and yet it's being recommended for "testing purposes" only? Note that PaX enables itself on all binaries by default, and that Ingo here does not argue that exec-shield=2 could result in a non-working system. Basically, his following argument, which I cannot refute, is that if exec-shield is DISABLED BY DEFAULT ON ALL BINARIES, then it results in a working system. Now, I remember some complaining about having to chpax java if you run it and PaX breaks it. How is that more work than running exec-shield in =1 mode, and having to explicitly enable it on all binaries you think should have protection, since you don't recommend =2 for production machines? Or, through what mechanism have you devised to notify the user when an application he thought was protected by exec-shield decides to mprotect an anonymous mapping rwx, thus making the main executable's bss and data sections executable? Viewing the process' maps file isn't going to tell you what kind of protection the process currently has. How about if someone mprotects a page of the stack rwx? Whoops, entire address space because executable. I'm also curious, given the rest of your model, how the lack of trampoline emulation is a security feature. From your announcement: To provide as good protection as possible, there's no trampoline workaround in the exec-shield code - ie. exec-limit violations in the trampoline case are never let through. Applications that need to rely on gcc trampolines will have to use the per-binary ELF flag to make the stack executable again. This all sounds very contradictory to your point that there's only one substantial difference between PaX and Exec-shield (funny how it was never mentioned that PaX is a true per-page implementation, while yours is much more coarse grained...that sounds pretty substantial too). Though, I don't know what I'm talking about here. Clearly every Debian developer who was kind enough to make useless non-technical posts to this thread know much more about this subject than I do. So please, listen to your in house "security experts" instead of me. They're probably better for a good laugh, anyways. -Brad
