fglrx has a real built-in overflow that's being detected by PAX when X loads, resulting a system hang. As a workaround we must disable CONFIG_PAX_USERCOPY and since 11.8 we also need to disable CONFIG_PAX_MEMORY_UDEREF. This of course makes our system less secure (at least on the PAX side) but fglrx can work ok. Another issue with fglrx (and possible the nvidia driver also) is that applications linked with libGL.so have to be marked with -m (disable MPROTECT) because fglrx's libGL.so results a RWX denied memory access. Here is a script to help with that... --- #!/bin/bash PATHTOLIST=`echo ${PATH} | sed s/:/" "/g` LIBEXECDIRS=`ls -lA /usr/libexec | grep drwx | awk -F" " '{print "/usr/libexec/"$9}'` BINDIRS="${PATHTOLIST} /usr/libexec ${LIBEXECDIRS}" DIRCONTENTS="" for i in ${BINDIRS}; do echo "Searching directory $i..."; DIRCONTENTS=`ls -A $i`; for c in ${DIRCONTENTS}; do ldd $i/$c |& grep -q $1; if [ $? == 0 ]; then echo -e "Fixing $c"; paxctl -m $i/$c; fi done done --- Just run ./<script> libGL.so and it'll mark most of your binaries so that you can have a working desktop. Also /usr/bin/Xorg needs -m marking since it tries to load the dri module (fglrx_dri.so) and again gets a RWX denied access, since it's not linked with fglrx_dr.so directly (probably uses dlopen) ldd won't catch it with the above script. Without this DRI module wont load (but DRI extension will be anounced and apps will try to use it) and you 'll get segfaults on various progs (e.g. firefox) and non-working glx. Another thing the above script won't catch is binaries inside /usr/libexec/evolution/<version>* and various others. Keep an eye on /var/log/grsec.log for RWX denials related to libGL.so and mark the binaries with paxctl -m <binary>. It'd probably be better to use portage to do that. Use stuff from revdep-rebuild to get the binaries per packet and check them instead of hardcoding directories, or even better check if user has fglrx on VIDEO_CARDS and mark all files linked with libGL.so + /usr/bin/Xorg when emerging the related packages. With this script and the mentioned changes I can run a full desktop just fine, wine and games etc included ;-) Reproducible: Always Steps to Reproduce: 1. Install fglrx with PAX enabled 2. Try to load X,gdm etc Actual Results: System hang Expected Results: A working desktop
Hi Nick, We've been working on this issue and we have an experimental utility that should help. revdep-pax will mark all binaries which make use of libGL.so.1 with -m flag. Try the following: 1. unmask sys-apps/elfix and emerge >=sys-apps/elfix-0.4.1 2. paxctl -m /usr/lib64/libGL.so.1 2a. paxctl -v /usr/lib64/libGL.so.1 #as a check 3. revdep-pax -s libGL.so.1 -me The last command will show you all the executables which link against libGL.so and do not share the same flags as the library does. You will be prompted for each whether to mark it or not. Say 'y' to those you want to mark. Currently I do not have it saying yes automatically but I plan to add that flag --- like I said, this is still experimental so I erred on the side of caution.
Hello Anthony and thanks for the quick reply ;-) File "/usr/sbin/revdep-pax", line 105 print sv ^ SyntaxError: invalid syntax This is on 0.4.0, I probably miss the 0.4.1 update from my tree (just synced) but its good to hear we have something under development ;-) Note even if we do mark all binaries that link to libGL.so with -m we still need to deal with /usr/bin/Xorg that opens fglrx_dri.so with dlopen and the programs that come with ati-drivers under /opt/bin because they also call libGL.so and we can't mark them directly, we still have to do a -C to create the PT_PAX_FLAGS header. Another update: I got compiz working but I can't make ccsm to work without setting kernel.pax.softmode=1, it seems pygtk is calling libGL.so but I can't mark ccsm because it's not a binary, it's a python script. Should I mark the python interpreter binary ? Is it safe ? Thanks again and keep up the good work !
Created attachment 294823 [details] A simple bash script alternative to revdep-pax
I uploaded a new version of the script that now also works on subdirectories etc using find. This one successfully checks all ELF binaries located on any directory inside PATH + /usr/libexec and subdirectories, checks if we need to add PT_PAX_FLAGS and marks them with the passed arguments like revdep-pax, e.g. revdep-pax.sh -me libGL.so I think this solution is cleaner and covers also binaries that don't map to any packages. Anyway so this is what's needed to get fglrx working... revdep-pax.sh -me libGL.so paxctl -m /usr/bin/Xorg This still doesn't fix ccsm though and I guess any python program that uses pygtk... Traceback (most recent call last): File "/usr/bin/ccsm", line 32, in <module> import gtk File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 40, in <module> from gtk import _gtk ImportError: libGL.so.1: failed to map segment from shared object: Operation not permitted
paxctl /usr/bin/python2.7 -m paxctl /usr/bin/python3 -m did the trick but I don't like the idea of losing mprotect check on all python programs, anyway I guess there is no other way...
> > I think this solution is cleaner and covers also binaries that don't map to any > packages. > I will not support pax marking binaries that do not belong to packages. All an attacker need do is introduce a malicious binary which artificially links against libGL.so.1 and you've just removed its mprotect. I'm still debating whether or not to drop all ldd and just get the linking info from the package manager.
If some adjustment is needed to ati-drivers ebuild to better work with hardened (like additional kernel config checking or whatever), just open a bug and CC me. I don't have the time to install an gentoo-hardened system to do a complete testing so i will need some help :). I always bump new release to x11 overlay first, so you can test them there and report bugs before they hit the main portage tree.
The problem is still here, finding this bug took some time, why not add howto from comment 1 to pkg_postinst messages? It will help a lot. Also it possible to add some USE flag, that will run revdep-pax in pkg_postinst when enabled.
(In reply to comment #8) > The problem is still here, finding this bug took some time, why not add > howto from comment 1 to pkg_postinst messages? It will help a lot. Also it > possible to add some USE flag, that will run revdep-pax in pkg_postinst when > enabled. @x11 herd. revdep-pax (from the sys-apps/elfix package) is mature. You may want to add that to the pkg_postinst().
x11 herd only proxy commits for the maintainer
x11-drivers/ati-drivers has been removed, per bug 582406.
