On Fri, 2012-04-20 at 09:37 -0700, Toshio Kuratomi wrote: > On Fri, Apr 20, 2012 at 12:16:34PM -0400, Adam Young wrote: > > On 04/20/2012 10:47 AM, Toshio Kuratomi wrote: > > > > On Fri, Apr 20, 2012 at 09:42:26AM -0400, Adam Young wrote: > > > > One caveat. Any DJango app (Probably most Python wsgi apps, > > actually) is > > going to give an AVC Denial warning upon startup. > > > > Only a denial? ;-) Do you have selinux in permissive? > > > > In enforcing it still gives a denial.... > > 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. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=814391 > > > > > > That's sorta a duplicate of this bug; > > https://bugzilla.redhat.com/show_bug.cgi?id=582009 > > > > (AFAICS, they're the same, but yours is against RHEL and mine is against > > Fedora). > > > > > > 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. > > > Upstream python doesn't like ctypes because it allows python code to more > easily create obscure bugs but it likes it more than the alternatives. The > reason is that upstream python is very friendly to the alternate language > vms/interpreters. Those alternatives often can't work with the python > C-API/ABI. But they can work with ctypes. > > > > > 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. > > > > 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. > > > The previous python maintainer actually wrote the patch to have it write out > to disk because we have SELinux set to prevent execmem by default. Writing > to disk is "better" in that it allows noexecmem by default on Fedora. > > > However, for libraries shipped with Fedora, there should be no need to use > > ctypes. > > > If you're talking about changing uuid into an extension module, then see > above as to why that isn't an upstreamable change.
It may be possible to fix the issue with uuid with a one-line change to ctypes which makes it avoid the SELinux-unfriendly codepaths unless absolutely necessary (uuid doesn't use them): see https://bugzilla.redhat.com/show_bug.cgi?id=814391#c2 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
