Request to upgrade DJango

[David Malcolm]

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