Page 1 of 1

X not working on kernel 2.6.24.5-grsec

PostPosted: Sat May 03, 2008 9:52 pm
by xQ-
Hello everyone, first of all I'd like to congratulate the development team for doing such a good work.

Second of all, I'd like to ask if someone had similar problems to mines.
I'm running a Debian 4.0 system mostly for desktop use with a 2.6.18-6 kernel. I downloaded the 2.6.24.5 archive, patched it with grsec, and compiled + installed it.
Everything is fine, I can boot it, but I have some problems after. I'm running virtualbox on this system which has a few modules at startup to provide networking to the VM's and other features. I get a *modprobe failed, check dmesg for more info on the new kernel, but that's not my problem. I have a Nvidia GeForce 8500 GT video card which works perfectly under the 2.6.18 with Nvidia's drivers (installed with Envy - http://www.albertomilone.com/nvidia_scripts1.html ). As soon as X is trying to start, I get errors containing: "dlopen: cannot enable executable stack as shared object requires" for nvidia's .so, libglx.so and a few others. I have tried chpax -sprm'ing them but that didn't work, no change at all. Also I noticed that when i tried to launch the widely known Lynx browser I get the same error for liblz.so.1. My question is what's causing it and how could I fix it ? Do I need to disable any grsec policies ?

I have attached my config for the 2.6.24 kernel, it's mostly a make oldconfig + the new stuff I was prompted for, including grsec..
http://pastebin.com/m6c52cb85

EDIT1: I have disabled PAX_MPROTECT feature in the kernel config, rebuilt it and the same problem...so it's not a mprotect issue.

Thanks in advance.

Re: X not working on kernel 2.6.24.5-grsec

PostPosted: Sun May 04, 2008 3:09 pm
by Oscon
xQ- wrote:
As soon as X is trying to start, I get errors containing: "dlopen: cannot enable executable stack as shared object requires" for nvidia's .so, libglx.so and a few others. I have tried chpax -sprm'ing them but that didn't work, no change at all. Also I noticed that when i tried to launch the widely known Lynx browser I get the same error for liblz.so.1. My question is what's causing it and how could I fix it ? Do I need to disable any grsec policies ?

EDIT1: I have disabled PAX_MPROTECT feature in the kernel config, rebuilt it and the same problem...so it's not a mprotect issue.

Thanks in advance.


I have got a bit tip.maybe.

Try with this patch...(it is from >=pax-2.6.24.y-test43):

Code: Select all
diff -Nru 2.6.24.4-42/fs/exec.c 2.6.24.4-43/fs/exec.c
--- 2.6.24.4-42/fs/exec.c   2008-04-29 15:42:16.000000000 +0200
+++ 2.6.24.4-43/fs/exec.c   2008-04-29 15:42:28.000000000 +0200
@@ -619,6 +619,10 @@
 
    vm_flags = vma->vm_flags;
 
+#ifdef CONFIG_PAX_SEGMEXEC
+   vm_flags |= VM_STACK_FLAGS & (VM_EXEC | VM_MAYEXEC);
+#endif
+
    /*
     * Adjust stack execute permissions; explicitly enable for
     * EXSTACK_ENABLE_X, disable for EXSTACK_DISABLE_X and leave alone
@@ -628,8 +632,6 @@
       vm_flags |= VM_EXEC;
    else if (executable_stack == EXSTACK_DISABLE_X)
       vm_flags &= ~VM_EXEC;
-   else
-      vm_flags = VM_STACK_FLAGS;
    vm_flags |= mm->def_flags;
 
 #if defined(CONFIG_PAX_PAGEEXEC) || defined(CONFIG_PAX_SEGMEXEC)

Re: X not working on kernel 2.6.24.5-grsec

PostPosted: Sun May 04, 2008 5:43 pm
by xQ-
Yes, that works. Thanks alot. Is there anything else I should look for that could be malfunctioning ? (My GNOME Network Monitor applet spits a Permission denied trying to open /proc/net/dev already, but that's not a problem at all.)

Re: X not working on kernel 2.6.24.5-grsec

PostPosted: Mon May 05, 2008 9:13 am
by Oscon
xQ- wrote:Is there anything else I should look for that could be malfunctioning ?


some exploits, etc. for example. ;-)


xQ- wrote: (My GNOME Network Monitor applet spits a Permission denied trying to open /proc/net/dev already, but that's not a problem at all.)


You have chosen these kernel-options:

Code: Select all
CONFIG_GRKERNSEC_PROC=y
# CONFIG_GRKERNSEC_PROC_USER is not set
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_GID=1001
CONFIG_GRKERNSEC_PROC_ADD=y


you will have restricted access to /proc fs unless you are a member of the 1001 group

Re: X not working on kernel 2.6.24.5-grsec

PostPosted: Wed May 14, 2008 9:15 am
by Alexei.Sheplyakov
xQ- wrote:
"dlopen: cannot enable executable stack as shared object requires"


when i tried to launch the widely known Lynx browser I get
the same error for liblz.so.1.


This was answered *really* many times, see e.g.

viewtopic.php?f=3&t=1747

Please search the forum before asking questions.

I have a Nvidia GeForce 8500 GT video card which works perfectly under
the 2.6.18 with Nvidia's drivers


You need to

Code: Select all
paxctl -spc /usr/bin/Xorg


(and probably other binaries using OpenGL libraries).

Explanation: nvidia OpenGL library generates code at the runtime.
This is a bad idea on its own (because Xorg runs with superuser
privileges). Moreover, that library assumes every writable memory
to be executable, and don't even care to mprotect it. So, you need
to disable PaX features for Xorg binary (and probably other programs
using OpenGL).


Code: Select all
EDIT1: I have disabled PAX_MPROTECT feature in the kernel config,
rebuilt it and the same problem...so it's not a mprotect issue.


I think it is. As I explained previously, nvidia's junkware don't
even care to mprotect dynamically generated code (strace Xorg to
check this).

Re: X not working on kernel 2.6.24.5-grsec

PostPosted: Wed May 14, 2008 9:18 am
by Alexei.Sheplyakov
Oscon wrote:
Try with this patch...(it is from >=pax-2.6.24.y-test43):


I think your patch kind of denies the purpose of PaX (unless I'm
missing something, that is).

Re: X not working on kernel 2.6.24.5-grsec

PostPosted: Thu May 15, 2008 6:35 am
by PaX Team
Alexei.Sheplyakov wrote:
Oscon wrote:
Try with this patch...(it is from >=pax-2.6.24.y-test43):


I think your patch kind of denies the purpose of PaX (unless I'm missing something, that is).
it was an actual regression fix, without it disabling MPROTECT had no effect on a SEGMEXEC enabled kernel (for the stack vma that is, so the usual advice for working around unpatched glibcs' behaviour with GNU_STACK didn't work).