From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: the SELinux folks are trying to introduce mprotect() API restrictions. One variant of those restrictions is to not allow mprotect() on writable mappings. A modified version of Roland McGrath's kernel patch to rhselinux-list shows that X is mprotect()-ing what seems to be malloc() areas: #2 X/2943: 0822f000-08232000 (00100077). #2 X/2943: 08232000-0824a000 (00100073). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. start X 2. 3. Actual Results: X crashes. Expected Results: X works fine. Additional info:
The Xorg ELF loader is the culprit here. We enhanced the ELF loader a year or two ago to call mprotect to flag memory regions with PROT_EXEC in order for the X server to work with exec-shield. The upstream X.Org project is currently planning on disabling the ELF loader in X11R7, and using the dlopen loader instead, which will have a nice side effect of resolving this issue, however that wont likely be until the Fedora Core 5 / RHEL 5 timeframe. If this feature request is intended for FC4 and/or RHEL4_Un updates, we'll need to evaluate the ELF loader to determine how much effort it might take to rework it to not require mprotect. I've CC'd John Dennis, as I believe he did the mprotect enhancements initially, and might be able to provide some useful comments. I'll bring this up on a future X devel team confcall to discuss also.
To be clear, it is perfectly fine to be using mprotect. The issue is the use of mprotect on memory from malloc, sbrk, or static memory regions such as big global arrays. That's what appears to be happening. If the loader allocates memory with mmap and then uses mprotect on that, this should not be a problem. Of course it can then just use the protection bits in needs in the original mmap call.
I'm going on memory here with respect to how the code works, but I'm pretty sure it does call mprotect on memory obtained from malloc. I'm not sure its worth trying to rewrite the code if the X ELF loader can be replaced with dlopen. So this might boil down to an issue of timing as to when the dlopen version the X server is available.
Oh, almost forgot, its not just the X server which is setting execute permission on memory. DRI and the OpenGL client library also does it.
This should all be resolved now with X11R7 in Fedora Core 5. If there are any remaining issues, they should be reported in X.Org bugzilla and tracked there. Setting status to "RAWHIDE"
So, can somebody plase make sure the now unnecessary permissions are removed from the SELinux policy?