<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 04/20/2012 10:47 AM, Toshio Kuratomi wrote: <blockquote cite="mid:20120420144755.GS28774@unaka.lan" type="cite"> <pre wrap="">On Fri, Apr 20, 2012 at 09:42:26AM -0400, Adam Young wrote: </pre> <blockquote type="cite"> <pre wrap=""> One caveat. Any DJango app (Probably most Python wsgi apps, actually) is going to give an AVC Denial warning upon startup. </pre> </blockquote> <pre wrap=""> Only a denial? ;-) Do you have selinux in permissive?</pre> </blockquote> In enforcing it still gives a denial.... <blockquote cite="mid:20120420144755.GS28774@unaka.lan" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">DJango imports Python's UUID module which in turn imports ctypes. Ctypes does dynamic code generation, specifically by writing a file andd then trying to execute it, which, as you can imagine, is a pretty big security hole. Let the wsgi community know that, until we have that fixed, we should not attempt to get rid of the AVC denial warning message, but instead should push on the Python upstread to get a fix in. Yes, David Malcolm is aware of it. <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=814391">https://bugzilla.redhat.com/show_bug.cgi?id=814391</a> </pre> </blockquote> <pre wrap="">That's sorta a duplicate of this bug; <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=582009">https://bugzilla.redhat.com/show_bug.cgi?id=582009</a> (AFAICS, they're the same, but yours is against RHEL and mine is against Fedora).</pre> </blockquote> Yes, they are the same, but mine has to do with the fact that it is part of the core library calling into ctypes. They can be addressed and fixed separately. <blockquote cite="mid:20120420144755.GS28774@unaka.lan" type="cite"> <pre wrap=""> I discussed it with dmalcolm when I opened it in 2010 -- it's not easily solvable. * By its nature, libffi needs to generate code that it then executes.</pre> </blockquote> I think this is the crux of the matter. I do not think that libffi needs to write this code out to disk to read it back in. It would be better if it held it in memory, but even that would probably be disallowed by SELinux. I suspect that there are better ways to do this form of dynamic binding that does not require code generation. However, for libraries shipped with Fedora, there should be no need to use ctypes. <blockquote cite="mid:20120420144755.GS28774@unaka.lan" type="cite"> <pre wrap=""> * Because python is interpreted, selinux has no transition to tell it that this is a specific program that needs to be able to write and execute specific files * Because the python interpreter is being embedded inside of apache, selinux has no way of differentiating it from any other piece of apache. The way out that I suggested in 2010 was to have a search path. Python would loop through the search path to find which directory it could use to write its temporary files for ffi. We'd need a way to set this path when applications start up (maybe in their httpd.conf) as mod_wsgi allows applications to run as different users than apache (which means that each wsgi application might need a different ffi directory). The sysadmin or wsgi application package would be responsible for creating the ffi directory and setting the appropriate selinux context on it. dmalcolm might not have liked that idea because of all the visible changes it would have to do (configuring the directories to search). Or it might just have been too much time to expend. I'm not sure. btw, the workaround is to set httpd_tmp_exec --> on -Toshio </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ epel-devel-list mailing list <a class="moz-txt-link-abbreviated" href="mailto:epel-devel-list@redhat.com">epel-devel-list@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/epel-devel-list">https://www.redhat.com/mailman/listinfo/epel-devel-list</a> </pre> </blockquote> </body> </html>