Re: [OT] PaX

[pageexec_(_at_)_freemail_(_dot_)_hu]

> Look, this is utterly ridiculous.

At least this one we agree on ;-).

> Apparently you cannot keep to the facts.

Well, to be honest, you haven't been exactly forthcoming
with yours either whereas i did provide you with proper
online references to the standard i was talking about.
Where's yours?

> > OpenBSD couldn't support PROT_EXEC until 3.2 on any architecture,
> 
> False.

On which arch did OpenBSD have proper PROT_EXEC semantics before 3.2
(all memory areas, not only stack)? I'm merely asking, i'll happily
give you this one and say 'most' instead of 'any'.

> > Therefore any mprotect() request not
> > asking for PROT_EXEC shall fail, but they don't.
> 
> Shall?  False.

Can't you read the standard? I've shown you the relevant excerpt,
if you think that's false, then tell us why.

> > It's also clear
> > that the standard anticipates implementations that are not able
> > to provide all possible protection types so it's well within the
> > spec to not provide them all, just make it clear to userland (by
> > failing the offending mprotect() call - which PaX does).
> 
> You make it fail on all architectures, hence, False.

What is your logic in there? If i make mprotect() fail on not all
archs, it suddenly becomes acceptable? Besides, of course i ensure
that PaX has the same security features on all supported archs (well,
to the extent it's possible), hence the same behaviour of mprotect().

> > Speaking of POSIX compliance, consider checking your own mmap()
> > implementation for example. The spec says this:
[...]
> The above commentary is False.

Which part? The facts were taken from the standard and your own CVS
tree in case you haven't noticed, they can hardly be false. If you
think the standard doesn't cover your case, feel free to explain it.

> > That's when you modify non-compliant software to bring it in line
> > with what the standard says.
> 
> False.  You go too far.

So when you modified gcc's trampoline handling it was 'false'?

> > Given our attack model, it's required. For details please see the
> > docs at http://pageexec.virtualave.net/docs/ .
> 
> Given that you are more than happy to break programs that generate
> native code inside their own images, False.

Who told you that i was happy with breaking programs? That's why PaX
features can be disabled both in the kernel configuration and on
individual binaries as well (or using ACLs under grsecurity). Last
but not least, what exactly is 'false' with the above? The statement
was about the PaX attack model and what is required to support it,
if you think the support is not required, prove it, preferably by
reasonable arguments, not sweeping comments.

> > The other approach is called SEGMEXEC and is based
> > on the segmentation logic. Its performance impact i don't know exactly
> > as i never tested it standalone,
> 
> Never tested?  So people are using the slow one?

Uhm, you didn't understand something. I never tested its *performance*
standalone. And i did tell you somewhere below that SEGMEXEC was the
default, did you miss it?

> W^X on i386 and all our other architectures has zero slowdown. On some
> architectures like sparc64 and powerpc, it actually sped the system up
> because we can avoid I cache flushes.

You're mixing up non-executable page semantics (what SEGMEXEC is about)
with restricting page protections, the two are different, even if the
latter requires the former.

> > There are bugs other than linear stack overflows which may still
> > allow a return-to-libc style exploit (and in your case, totally
> > circumvent W^X), what are you doing about them?
> 
> Nothing yet.  W^X is a piece of the puzzle.  Just as your "killing exec"
> thing has nothing to do with this either.

It does, but if you didn't understand the PaX docs so far, it's
pointless to explain it again.

> > PaX doesn't require changes in (most of) userland to provide all
> > the protection features.
> 
> And ours does, so that we do not suffer performance like PAX.

What performance do you 'suffer' under PaX (and which arch)?

> > No, PaX does not break mprotect(), it does what the standard allows.
> 
> No, it breaks the standard and there are affected applications.

You keep talking about the standard and how it's getting broken by
PaX. Can you finally serve us with the details? As i showed you
already, restricting protection flag combinations is allowed, but
you have to tell userland about it, which is where OpenBSD itself
fails.

> > Besides, if an app does need the relaxed behaviour, it can be allowed
> > by simply setting an ELF header flag on the given binary.
> 
> By modifying the binary.  So much for it being a kernel-only change!

Wrong, the PaX security features require a kernel-only change (for now,
that is), when you do NOT want them is when you have to set a flag.
Beyond this, you don't need to touch any of your binaries if you're
using grsecurity whose ACL system allows to disable PaX features on
a per subject basis.

> > TLB handling is not slow in PaX per se,
> 
> False.  Execute bit emulation in PAX is slow.

Tell us please how you can do it significantly faster (remember,
here we're talking about the paging logic, not segmentation).

> > PaX is already part of several distros, mostly because they use
> > grsecurity. One can get it on Mandrake, Debian, Trusted Debian,
> > Gentoo, etc.
> 
> And it is NOT ON BY DEFAULT!  Can you not READ WHAT I SAID?  I said

Did i say it was? Also, it's on by default in Trusted Debian.

> Can't you read?  Do you have some built-in desire to purposefully
> misread what people say, just so that you can win your little
> arguments?  Does it make you feel like a big man?

Weird, i thought i'd clearly avoided the word 'RedHat' when referring
to distros that use PaX.

> No, it is a bit unfair for people to say that what we've done in
> OpenBSD should give credit to PAX.  Considering we'd never heard of
> PAX before we did W^X,

http://marc.theaimsgroup.com/?l=openbsd-tech&m=97416533704634&w=2

By the way, i saw in your CSW03 presentation that you're planning
mmap and main executable randomization. It's got nothing to do with
http://pageexec.virtualave.net/et_dyn.zip and PaX's ASLR, right?

> and considering that our goal was to NOT BREAK anything -- a goal
> you have NOT MET.

You mean a goal i haven't set? FYI, it was something like 'maximum
possible compatibility without sacrificing the protection features'.
There are people who value security over the ability to run Java.

> > You realize that you control everything
> > (kernel+userland) in OpenBSD which is not true in our case.
> 
> Of course we do.  And that allows us to NOT BREAK semantics. 

You already start from a position where you break POSIX.