On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote:
> > The test incorrectly assumes that thread stacks are executable. I suspect
> > we both agree that it's desirable to have thread stacks non-executable as
> > well.
>
> while i agree with you on this one, it is in stark contrast to what you
> said earlier:
>
> > there's nothing wrong about an executable stack though. It's been part of
> > Linux ever since.
sorry but i really have to say that your logic is flawed. (It's sad to see
when a discussion deteriorates to such a stage and i've decided to stop it
from my side, see more below. [ thousands of debian-devel readers rejoice
:-) ] )
"The test incorrectly assumes that thread stacks are executable" is not
equivalent to "thread stacks are non-executable". And there's no conflict
in what i say above.
all i'm saying is that each and every application has a fair right to
assume an executable stack. _If_ tools find (or developer asserts it, in
the source) that a particular application does _not_ need an executable
stack then it's perfectly fine for the OS to go for it and enable a
non-executable stack!
you should not do this decision for the application/library in one way or
another.
> also, the test does not only demonstrate that thread stacks are
> executable or not, it demonstrates a fundemental design flaw in
> Exec-Shield: whenever an executable region is created in the address
> space, *everything* below that becomes executable as well. [...]
thanks, the cat is finally out of the bag - you admit here that the
incriminating paxtest code is there to demonstrate what you characterise
as a flaw in exec-shield. Note that none of your arguments tries to claim
that any real application indeed does "mprotect(argv)", which is pretty
telling by itself.
As i have explained it a hundred times, this behavior is a well-known
property of exec-shield, and that we've done a quite good job of reducing
this effect. In fact i've put it into my exec-shield announcement:
# Limitations:
# ------------
#
# also, if the overflow is within the exec-shield itself (e.g. within the
# data section of one of the shared library objects in the ASCII-armor)
# then the overflow might be possible to exploit.
#
# [...]
# All in one, exec-shield is one barrier against attacks, not blanket 100%
# protection in any way. The most efficient security can be provided by
# installing as many layers as possible.
But you dont have to believe me, you can try it yourself, install an
exec-shield distro and measure the effect of this exec-shield property.
( sorry, but i'm going to stop contributing to this thread. You are
getting increasingly irrational and emotional, there's nothing more i
could add to this thread. I do acknowledge that PaX is more secure, but i
also say that exec-shield is a hell alot of a difference from a stock
distro. You expressed your feelings that exec-shield is insecure in one
area and apparently you conclude that it's thus useless. There's nothing i
can do to change this irrational bad logic of yours. )
Ingo
ps. for those who'd like to get rid of this thread too, put this into
your .procmailrc:
:0:
* ^Subject:.*Exec-Shield vs. PaX
/dev/null
