Request to upgrade DJango

[Toshio Kuratomi]

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.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20120420/852539e0/attachment.sig>