Red Hat Bugzilla – Bug 488396
python ctypes triggers selinux execmem denial
Last modified: 2009-09-11 04:34:19 EDT
Description of problem:
ctypes doesn't import.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2. import ctypes
>>> import ctypes
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.6/ctypes/__init__.py", line 546, in <module>
This is caused by line 73 of malloc_closure.c. SELinux won't allow PROT_WRITE and PROT_EXEC on mmap. Any problems with patching this line to remove the PROT_EXEC?
Or is this known and required, and I am simply mislabeled?
Just removing PROT_EXEC causes a segfault instead. I'm guessing libffi writes some glue here.
Oddly enough, this should be failing at least sometimes on F10, but I cannot get selinux to reject my execmem request, even though the booleans are set.
Basically, something like this must be implemented:
Ok, the solution is to remove malloc_closure.c and use ffi_closure_alloc and ffi_closure_free. libffi has the correct support for selinux and does execmem in a safe way. I will see if I have time to whip up a patch.
Created attachment 335477 [details]
Patch to use selinux-friendly libffi alloc/free (requires system libffi)
It looks like we're between a rock and a hard place here, as this looks like it's changing the API and ABI for ctypes. Saying that nothing outside of the ctypes.so seems to use it. We could also minimize the change by keeping the variable pcl and putting pcl_exec at the end of the struct.
It'd be nice if you could get this upstream :).
Jeremy, ivazquez ... opinions?
Interesting. I don't believe that this changes API, since ctypes.h is not installed anywhere, and the Python interfaces don't seem to change. You can verify this by doing in Python:
>>> import _ctypes
And the ABI is I believe safe too, since I think CThunkObject is completely private and only used internally to the module, not exposed anywhere.
I am not 100% sure I didn't miss something.
As a side note, building with system libffi definitely changes the ABI, since ffi functions are no longer exported from this module. But I would say _ctypes.so is a totally private thing, and so this doesn't matter. It starts with an underscore after all.
http://bugs.python.org/issue5504 is the upstream bug.
I built it into rawhide after comment#7 and some more grepping, so it should be fixed now. Can you test?
Yes, it looks good now. I had to pull from koji, since it is not tagged into the f11-beta.
Added rel-eng request to tag into the beta:
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Is this supposed to be fixed in current F11 python?
I'm seeing an apparently ffi-related execmem denial with a django app in F11, which I just extended to use ctypes.
open("/tmp/ffiUce9Wm", O_RDWR|O_CREAT|O_EXCL, 0600) = 24
unlink("/tmp/ffiUce9Wm") = 0
ftruncate(24, 4096) = 0
mmap(NULL, 4096, PROT_READ|PROT_EXEC, MAP_SHARED, 24, 0) = -1 EACCES (Permission denied)
close(24) = 0
shortly after _ctypes.so was loaded - will try to narrow down to a repro case.
Filed bug 522731 for the fact that ctypes still breaks if used with httpd in an embedded interpreter.