Re: [gentoo-hardened] 2.6.27-hardened-r8: assassination

[pageexec@freemail.hu]

On 8 Mar 2011 at 15:55, Mike Frysinger wrote:

> On Tue, Mar 8, 2011 at 3:49 PM, Anthony G. Basile wrote:
> > Nothing to say that Mike hasn't already said.  pipacs knows about this
> > but what can he do?  Good luck with upstream glibc.  Next time I speak
> > with pipacs I can bring it up, see if anything is changing.  I doubt it.
>
> if there is a real bug in glibc that drepper is ignoring, that doesnt
> mean we cant merge it into Gentoo's glibc.  hence open a bug in
> bugs.g.o with the patch for me to review.

it's not just a glibc bug, it's the whole shit concept of GNU_STACK and
all it brings with it, see my Nth explanation here:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611195#10

i can (and do) disable GNU_STACK handling in PaX, but userland is out of
my reach (well, technically i could do even that by hacking the page cache
but that's too ugly to even consider). so as far as i'm concerned, you have
the following choices in order of preference:

1. disable GNU_STACK processing (mostly in ld.so i think)
   - this should solve all current and future problems but it won't be a
     one-liner patch

2. fix at least the mprotect return value checks in ld.so
   - the patch is in the glibc bugzilla
   - this fixes only the segfaults, it won't let these app to work under PaX,
   - actually, you could modify the patch and on the first mprotect failure
     you can just not attempt the write to that relro variable (and not bother
     with the second mprotect obviously), that should then let the library load
     too (elsewhere gentoo already fixed the stack mprotect code and ignores
     *its* mprotect failures under PaX)

3. execstack -c affected libs/binaries from portage
   - at install time we can detect (and already do, iirc) RWE GNU_STACK headers
   - if such a GNU_STACK header is really needed, i.e., the given app/lib does
     need an executable stack (nested function trampolines are emulated under
     PaX so they just need EMUTRAMP enabled on the app) then disable MPROTECT
     on the app (and for libs, all apps using the given lib)
   - if the RWE GNU_STACK header is a false positive, either fix the app (if we
     have source code) or execstack -c for binaries.
   - this is again quite some work