KDE 3.5 doesn't work on 2.6.32.27-grsec

[amdfanatyk]

2.6.32.22-grsec built today with QKernelBuilder and kdeinit cannot be started. I went back on 2.6.32.11-grsec which works with no problems. I didn't try any version between 11 and 22.

[spender]

I need more information, logs for starters. Would also be nice to know if changing the PaX flags on kdeinit (or if some binary is crashing, whatever that binary is) resolves the issue. What distro and architecture, etc.

-Brad

[amdfanatyk]

/usr/bin/kdm_greet: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Operation not permitted

[spender]

You'll have to disable MPROTECT on each binary using libGL.so.1 with chpax -m or paxctl. In previous PaX versions, attempted RWX mappings were silently demoted to RW mappings. The fact that this worked fine previously suggests that libGL doesn't really need that mapping to be executable and should be fixed upstream. New versions of PaX reject RWX mappings so that the application can handle the error (like in the ClamAV case, it will attempt to use JIT with an RWX mapping -- if that fails, it safely falls back to an interpreter-based mode).

-Brad

[amdfanatyk]

But what is the point in doing so? I have to disable whole protection. And in addiction it's inconvenient. I don't see anything dangerous in auto-changing RWX to RW. That's stupid!!!

[spender]

The point is that prior to this, there was no way for an application that requested a RWX mapping that was silently demoted to know that it was demoted, so they would assume it was executable and upon trying to execute in it, would be terminated by PaX. SELinux does the same rejection of mappings, and since applications are being written specifically with SELinux support, they're now performing these checks to make sure their mmap completed successfully. If it doesn't succeed, then they can fall back to a different mode of operation. Removing the silent demotion makes this possible under PaX as well, whereas before it was impossible (unless we too were able to modify every applicable upstream code).

We've considered implementing a option for a "compat" mode of MPROTECT which would allow you to select the previous MPROTECT behavior.

-Brad

[amdfanatyk]

Since I cannot count on Your support, the only solution for me to run 2.6.32.27-grsec seems to be:

Code: Select all

--- mmap.c_org   2011-01-09 22:46:23.000000000 +0100
+++ mmap.c   2011-01-09 22:47:59.000000000 +0100
@@ -1051,12 +1051,7 @@
       if ((vm_flags & (VM_WRITE | VM_EXEC)) == (VM_WRITE | VM_EXEC)) {
          gr_log_rwxmmap(file);
 
-#ifdef CONFIG_PAX_EMUPLT
          vm_flags &= ~VM_EXEC;
-#else
-         return -EPERM;
-#endif
-
       }
 
       if (!(vm_flags & VM_EXEC))
@@ -2750,7 +2745,7 @@
 #ifdef CONFIG_PAX_MPROTECT
    if (mm->pax_flags & MF_PAX_MPROTECT) {
       if ((vm_flags & (VM_WRITE | VM_EXEC)) == (VM_WRITE | VM_EXEC))
-         return -EPERM;
+         vm_flags &= ~VM_EXEC;
       if (!(vm_flags & VM_EXEC))
          vm_flags &= ~VM_MAYEXEC;
       else


[amdfanatyk]

grsec: denied RWX mmap of /usr/lib/libGL.so.256.53 by /usr/bin/ksplash
grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/ksplash
grsec: denied RWX mmap of /usr/lib/libnvidia-glcore.so.256.53 by /usr/bin/ksplash
grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/ksplash
grsec: denied RWX mmap of /usr/lib/libGL.so.256.53 by /usr/bin/kdeinit
grsec: denied RWX mmap of /usr/lib/libGL.so.256.53 by /usr/bin/kadu
grsec: denied RWX mmap of /usr/lib/libnvidia-glcore.so.256.53 by /usr/bin/kadu
grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/kadu
grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/kdeinit

Personally I don't think any of these mappings will ever be fixed because everything apart from NVIDIA driver is no longer supported. NVIDIA has very low quality Linux support so I don't think they will be able to fix anything.

[gengor]

Hi amdfanatyk,

I was browsing through the latest forum posts and noticed the patch you are applying in order to use Nvidia drivers. I have not looked at the patch in-context (applied) but at a glance it looks like a bad patch & not good idea.

This should be a better patch to do what you're wanting to do (it reverts to PaX-MPROTECT's historical behavior): https://gist.github.com/a3f6d7aa9f6aec1 ... 7849dc08d9

... the patch is against 2.6.32.x+recent grsecurity. Make sure to use the exact revision the above link takes you to, and not any prior revisions in the page's sidebar.

Disclaimer: I make no warranties or guarantees of any kind on this patch, you use the patch at your own risk. That said, there are no issues known to me with the above-linked patch.

[gengor]

Hi amdfanatyk,

The above functionality is now available in the latest stock grsecurity patch. You can drop the patch and instead flip on the PAX_MPROTECT_COMPAT option.