Re: Grsec/PaX and Exec-shield

[spender@grsecurity.net]

On Tue, Nov 04, 2003 at 06:49:58PM +0100, Ingo Molnar wrote:
> 
> On Tue, 4 Nov 2003 spender@grsecurity.net 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