FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 04-20-2012, 04:37 PM
Toshio Kuratomi
 
Default Request to upgrade DJango

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 04-20-2012, 06:25 PM
David Malcolm
 
Default Request to upgrade DJango

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
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-17-2012, 08:37 PM
Adam Bishop
 
Default Request to upgrade DJango

Hello,

I noticed that Django-1.3 has spent 14 days in the testing branch as of yesterday - do you plan to release it now, or does additional testing need to be done on it?

Thanks,

Adam Bishop
Access & Identity Management
Janet
Direct line: +44 (0)1235 822 245
Janet, the UK’s education and research network

On 20 Apr 2012, at 19:25, David Malcolm wrote:

> 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
> epel-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list


Janet is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-18-2012, 07:06 PM
Matthias Runge
 
Default Request to upgrade DJango

On 17/05/12 22:37, Adam Bishop wrote:

Hello,

I noticed that Django-1.3 has spent 14 days in the testing branch as
of yesterday - do you plan to release it now, or does additional
testing need to be done on it?

Thanks,


Already released. We're using a feedback system for packages.
If a package get's enough karma, it can be pushed to stable (or after 14
days in testing, depending which happens earlier). So I encourage all
users to give feedback!


(Adam, you did that, thank you!)
--
Matthias Runge <mrunge@matthias-runge.de>
<mrunge@fedoraproject.org>

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 12:39 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org