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. 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:

                                stock         exec-shield     PaX
  ---------------------------------------------------------------
  environment/argv/aux          no            yes             yes
  stack                         no            yes             yes
  anon mmaps                    no            yes             yes
  malloc()                      no            yes             yes
  binary bss/data               no            yes             yes
  lib bss/data                  no            no              yes

> [...] So I wonder what happens when someone tries to run tuxracer on a
> system that doesn't use PT_GNU_STACK?  Will Exec-shield then break
> "binary compatibility" without the presence of its self-made "standard"?

what do you mean? tuxracer runs just fine here.

If you mean exec-shield=2 then it is 'forcing' exec-shield and is only
recommended for testing purposes. Running exec-shield=1 on a system with
or without PT_GNU_STACK sections will result in a working system.  
PT_GNU_STACK itself influences nothing. Note that the Fedora kernel
defaults to exec-shield=1.

PT_GNU_STACK is a way to _automatically_ tag binaries/libraries whether
they need the stack to be executable or not. So instead of putting the
burden of 'chpax-ing broken applications' on the administrator or
distribution maker (and third party developers, and the scientific
community, and ...), this method tracks executability requirements
automatically. So you'll get a non-executable stack in like 99% of the
cases. It would be great if Debian adopted the PT_GNU_STACK changes too,
they can push the concept of non-executable stacks into the mainstream.

        Ingo


Reply via email to