Re: Grsec/PaX and Exec-shield
On Tue, Nov 04, 2003 at 06:49:58PM +0100, Ingo Molnar wrote:
> On Tue, 4 Nov 2003 email@example.com 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 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
> 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
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
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
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.