From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.0 (like Gecko) Description of problem: # readelf -l /usr/lib/libGL.so.1.2 |grep STACK GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 Let me know if it REALLY needs the executable stack and we can change SE Linux policy accordingly. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. 2. 3. Additional info:
libGL dlopen()s the individual DRI drivers, which in turn runtime allocate memory which gets used for runtime code generation, so the memory must be marked executable in order to function correctly. In previous versions of Mesa, it just blindly did this with the assumption all stack and heap memory was executable - thus making it cause exec-shield to be disabled. In XFree86 4.3.0 we had a custom Red Hat patch which made Mesa properly set up the memory to work nicely with exec-shield, however the patch was dropped due to being to much effort to forward port to every new release, and the code was rejected upstream. My understanding is that upstream has eventually re-implemented this in the mesa currently in rawhide, and that it now properly takes care of ensuring the memory it allocates is flagged PROT_EXEC when need be. If I'm reading your question right, the answer would be that Mesa does require dynamically allocated executable memory in order to have functional DRI support. Do you need any further info?
Surely if it's only the drivers that allocate such memory then only those drivers need to be marked as requiring write/execute access? This would mean that if you use a driver that needs such access then the access is granted, otherwise it isn't, while the current system grants such access even if no DRI drivers need it.
I'm probably not the best person to ask, as I'm not really intimately involved with the Mesa code. Ajax or krh can likely best respond.
Jakub fixed mesa some time back. The first question is why isn't that patch carried forward? It's a *HUGE* security risk to not do this because all those crappy desktop apps are linked against libGL. It's also a big step backward security-wise from previous versions of the distribution. I do not really know whether the problem was in libGL itself or in the modules which are loaded. Now that dlopen is used it is in theory indeed possible to mark only the modules requiring the executable stack as such and not libGL. I added Jakub to the cc list, he would know.
(In reply to comment #4) > Jakub fixed mesa some time back. The first question is why isn't that patch > carried forward? Jakub submitted it to Mesa upstream at one point, and it was rejected, or perhaps just ignored, I'm not completely sure. You might want to ask jakub directly though, as he probably has a better recollection. Porting patches forward every single OS release, in particular for something like Mesa which changes drastically every X release, is not viable from an engineering resource management/allocation perspective, in particular considering how strained our existing X development resources have been. It is a general policy of the X Development team, and has been for a very long time now, that any nontrivial work that is done, must be completed, submitted upstream by the author, and accepted into upstream CVS before we will consider including it in our packaging. This is a policy that was "defacto" for quite a while, but was put in place as an official policy by our team leader (kem) during development of various team policies. > It's a *HUGE* security risk to not do this because all those > crappy desktop apps are linked against libGL. Of course I'd agree with you on that. > It's also a big step backward security-wise from previous versions of the > distribution. Only from a single version: Red Hat Linux 9. If memory serves me correctly, that is the only OS release which has ever shipped with the custom Mesa patch. In retrospect, it was a mistake to include such a large custom patch at all, until it had been submitted and accepted by Jakub to the Mesa project. > I do not really know whether the problem was in libGL itself or in the modules > which are loaded. Now that dlopen is used it is in theory indeed possible to > mark only the modules requiring the executable stack as such and not libGL. We are currently not doing anything special to build Mesa that would cause libGL to be flagged with an executable stack. I discussed this with ajax last week, and I believe he indicated that the "linux-dri-x86" build target will require GNU stacks for some performance reason, but that the "linux-dri" target doesn't require it. I think we can all agree that having libGL not require an executable stack, is beneficial security-wise. I'd also agree that the DRI modules that require exec-stack should be the only thing that is flagged in that manner. I don't find it very beneficial in solving this problem to complain about past decisions that were made, or to wave fingers at people. Let's please just focus on solving the problems for once and for all, in a manner that is not going to cause us long term maintenance problems (such as a large custom patch we have to port forward every OS release). It shouldn't be difficult to solve this properly for FC5, so I'm adding it to the FC5Target list.
Additionally, I'd like to point out that the problem that the old exec-stack patch fixed, was ensuring memory allocated in the DRI drivers got flagged PROT_EXEC. That is all it did, and that is already in Mesa that is in rawhide. The problem being surfaced in _this_ bug report, is an entirely new problem which never existed in previous OS releases to the best of my knowledge. So kicking sand over an ancient problem that appears to have been resolved ever since Mesa 6.4.x hit rawhide, isn't useful.
Is there a workaround for this, so I can use libGL.so?
I guess I am hitting this problem? amarokapp: error while loading shared libraries: libGL.so.1: cannot enable executable stack as shared object requires: Permission denied
The upgrade which broke my metacity: $ sudo grep mesa-libGL /var/log/yum.log Feb 22 05:48:09 Updated: mesa-libGL.i386 6.4.2-3 Feb 22 05:49:58 Updated: mesa-libGLU.i386 6.4.2-3 Feb 22 05:54:27 Updated: mesa-libGLw.i386 6.4.2-3 The problem with metacity: $ metacity metacity: error while loading shared libraries: libGL.so.1: cannot enable executable stack as shared object requires: Permission denied The fix: # execstack -c /usr/lib/libGL.so.1 The problematic package: # rpm -q --whatprovides /usr/lib/libGL.so.1 mesa-libGL-6.4.2-3
i believe the only dynamic code generation Mesa does these days is done on the heap and/or in its own writable text section, and not on the stack.
But heap isn't executable either when PT_GNU_STACK program header says PT_R|PT_W. Unless Mesa explicitly mmaps the memory for dynamically generated code with PROT_EXEC (or better, yet, creates with PROT_READ|PROT_WRITE and when done mprotects with PROT_READ|PROT_EXEC), things won't work properly.
*** Bug 182380 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > But heap isn't executable either when PT_GNU_STACK program header says PT_R|PT_W. > Unless Mesa explicitly mmaps the memory for dynamically generated code with > PROT_EXEC (or better, yet, creates with PROT_READ|PROT_WRITE and when done > mprotects with PROT_READ|PROT_EXEC), things won't work properly. yes, i believe it does the mprotect method now, even for the -x86 build target. i'll check of course.
Re comment #5: > Porting patches forward every single OS release, in particular for something > like Mesa which changes drastically every X release, is not viable from > an engineering resource management/allocation perspective, I do not agree at all. You cannot insist on a pristine package if upstream isn't willing to pick up critical patches. This is the way things work. Every package maintainer has such patches they'd like to get rid of. We have to set priorities and GL disabling all the security features for the entire desktop is simply no option IMO. Yes, it might mean more resource requirements on our side (esp the X team) but this is a crucial part of the security of the system. As Mark's analysis showed, 100% of the security problems of RHEL4's first year are in the desktop programs, not the server side. I'm not saying Jakub patch does everything it now has to do and therefore it's easy to integrate. It's rather unlikely, the original patch mainly dealt with the stack and perhaps not using malloc for executable memory. The situation now is more complicated. You must avoid PROT_WRITE^PROT_EXEC mprotect. You cannot even change PROT_WRITE to PROT_EXEC. It's explained at http://people.redhat.com/drepper/selinux-mem.html That page also has some code explaining how to best solve the problem.
> Porting patches forward every single OS release, in particular for something > like Mesa which changes drastically every X release, is not viable I totally agree with Uli. There are in RHEL, as well as FC, a number of security patches in packages that we carry forward each time due to them not being acceptable for whatever reason upstream. We are accountable for the risk our customers face using our distributions, and therefore responsible for doing everything we can to minimise that risk, even if upstream doesn't agree or it involves us doing some engineering work at the expense of other fixes or it's hard. Anyway this issue is no longer about patches being missed, it's a new issue, so it's something we need to fix in an update and then keep carrying forward if upstream reject it.
fixed in rawhide, iirc...
Backported the rawhide noexec-stack fixes to FC5 as of mesa-6_4_2-6_FC5_2. Update pending. The fix is already in upstream Mesa, and should be included in 6.5.1 and later.
*** Bug 191191 has been marked as a duplicate of this bug. ***
mesa-6.4.2-6.FC5.3 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
From comment #17, I assume this is already fixed in rawhide currently? The mesa update for FC5 already went out the door. This should be closed as "RAWHIDE" now if it's fixed I suppose.
(In reply to comment #20) > The mesa update for FC5 already went out the door. This should be closed > as "RAWHIDE" now if it's fixed I suppose. ACK, fixed in rawhide.