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
