Re: Exec-Shield vs. PaX
> > [...] 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 app was broken.
false! my unmodified X server (gentoo) dies with the following core
when trying to run it under [1]:
(gdb) bt
#0 0x00caf471 in kill () from /lib/libc.so.6
#1 0x00caf215 in raise () from /lib/libc.so.6
#2 0x00cb07bb in abort () from /lib/libc.so.6
#3 0x0806eb99 in AbortDDX ()
#4 0x080ed43a in FatalError ()
#5 0x0808522c in xf86SigHandler ()
#6 <signal handler called>
#7 0x0a226000 in ?? ()
#8 0x080a6f98 in LoadModule ()
#9 0x0806fa3c in xf86LoadModules ()
#10 0x0806db2a in InitOutput ()
#11 0x080d36c1 in main ()
does LoadModule() ring a bell? why don't you realize that there's a
world beyond RedHat and that you *do* break those people's system?
heck, you did break RedHat users' systems as well, you say so yourself:
[2] or [3]. every time you suggest that a user upgrade X means that
you have broken his existing binary - a clear no-no by your own rules.
> X does break if you force exec-shield=2, and it did break even with
> exec-shield=1 in earlier iterations of exec-shield, but that bug has been
> fixed.
excerpt from [1]:
--- linux/kernel/sysctl.c.orig
+++ linux/kernel/sysctl.c
@@ -52,6 +52,9 @@ extern int core_uses_pid;
extern char core_pattern[];
extern int cad_pid;
+int exec_shield = 2;
+int exec_shield_randomize = 1;
that to me means that *everyone* will have his *existing* binary
broken, by your own admission. it also means that you have
violated the very rule of Linus you had referred to before.
> the XFree86 patching you refer to above we did was to enable non-exec
> stack. But this was an iterative thing to enhance security, not something
> we had to do because X broke due to exec-shield itself.
XFree86 never needed an executable stack as far as i know, what was
there to 'enhance' then? it is clear that XFree86 did break because
of Exec-Shield and you had to modify both to get it to work and be
able to claim that it works out of the box. 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?
by the way, on another look at your patch i noticed the following:
1. you added a new parameter to fs/binfmt_elf.c:create_elf_tables()
but don't make use of it, probably it's not needed at all now.
2. in fs/exec.c:setup_arg_pages() you may create an inconsistent state
between mpnt->vm_page_prot and mpnt->vm_flags, the former should
be derived from the latter, just like do_mmap_pgoff() does it.
[1] http://people.redhat.com/mingo/exec-shield/exec-shield-2.4.22-G4
[2] http://marc.theaimsgroup.com/?l=linux-kernel&m=106482772021534&w=2
[3] http://marc.theaimsgroup.com/?l=linux-kernel&m=106502603232695&w=2
Reply to: