Summary: | ati-drivers don't work with PAX enabled | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nick Kossifidis <mickflemm> |
Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
Status: | RESOLVED WONTFIX | ||
Severity: | critical | CC: | enrico.tagliavini, jaak, jekarlson, nikoli, x11 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | A simple bash script alternative to revdep-pax |
Description
Nick Kossifidis
2011-12-04 20:31:16 UTC
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. |