[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: