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 ear
On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote:
> > there's nothing wrong about an executable stack though. It's been part of
> > Linux ever since.
>
> the brk() managed heap has also been executable. yet you break apps that
> assume so (the ominous XFree86 server would also use the brk() managed
>
On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote:
> [...] incidentally, if i were to make use of PT_GNU_STACK in PaX, i
> could claim the same - now what was your point of fighting this silly
> issue?
yes, this was precisely my point to discuss this issue. Executability of
the stack is not some divine
On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote:
> > actually, unmodified XFree86 works just fine. It will have an executable
> > stack but it will work out of box - so no app was broken.
>
> false! my unmodified X server (gentoo) dies with the following core
> when trying to run it under [1]:
you n
On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote:
> [...] also, you did break userland yourself as well, otherwise how would
> you explain the patches RedHat made to the XFree86 server?
actually, unmodified XFree86 works just fine. It will have an executable
stack but it will work out of box - so no a
On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote:
> > non-executable pages on anything else but i386 is a triviality, as the
> > hardware and the kernel supports it. There's virtually nothing that PaX or
> > exec-shield has to add to enable them - they are there.
You are right that the other architect
On Wed, 5 Nov 2003, Peter Busser wrote:
> It is in fact a simulation of a multithreaded application. [...]
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.
> I objected to adding tests that
On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote:
> > > glibc creates executable thread stacks by default. [...]
> >
> > to the contrary, glibc does this:
> > [snip]
> > $ rpm -q glibc
> > glibc-2.3.2-101
>
> that's what RedHat's glibc does. [...]
yes. The changes are in mainline glibc, everyone
On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote:
> > i downloaded the new 0.9.5 paxtest package and amongst other changes it
> > has the following oneliner change:
[...]
> > + do_mprotect((unsigned long)argv & ~4095U, 4096,
> > PROT_READ|PROT_WRITE|PROT_EXEC);
>first of all, it's multi
On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:
> second, paxtest had some bugs which Exec-Shield exposed and made
> Exec-Shield appear better than it is. i've fixed them here and
> expect to release 0.9.5 today or so. the results now look like:
i downloaded the new 0.9.5 paxtest package and a
On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:
> since a few points have been made regarding $subject, let me clear
> up a few of them:
>
> 1. 'It seems that exec-shield does 99% of what PaX does'
this is not the case and i'm not claiming it. If you feel attacked, please
dont - i'll stipulate that
On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:
> [...] Exec-shield "can" stop, but "will" stop is a completely different
> matter. I'll let the bugfixed paxtest tell this story, however.
i am 100% sure that by taking the range-property of exec-shield into
account you can construct 'bugfixed' mappin
On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:
> [...] 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? [...]
yes. It
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
On Tue, 4 Nov 2003, Peter Busser wrote:
> > the reply below is mostly a re-send of a mail i sent to you privately
> > but you repeat this argument again without any apparent answer to my
> > counter-arguments.
>
> I already suggested you to reread the PaX documentation, there are the
> answers
On Tue, 4 Nov 2003, Peter Busser wrote:
> - Running paxtest shows the differences between PaX and exec-shield.
> Everyone is invited to run paxtest to see for yourself.
the reply below mostly a re-sent of a mail i sent to you privately - but
you repeat this argument again without any appar
16 matches
Mail list logo
