Open Stack

On 04/20/2012 11:51 AM, Doug Hellmann wrote:
> Have you tried changing Dashboard to monkey patch the uuid module to 
> blank out the functions being loaded from ctypes? If the 
> _uuid_generate_* functions are not set, the existing python 
> implementation is used instead and it looks like that just uses 
> urandom() inline.

Good idea.  I will test that out this upcoming week.  The issue is that 
just importing ctypes causes the  ACV Denial,  so I am not sure how that 
will work when integrating with a Monkey Patch solution.  Have you tried 
it?  Do you see anything in /var/log/audit/audit.log?

>
> On Thu, Apr 19, 2012 at 11:53 AM, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     Did a little digging into an audit log message we've been seeing
>     specifically on Dashboard.
>
>     They look like this in audit.log
>
>     type=AVC msg=audit(1334860567.213:5184): avc:  denied  { execute }
>     for  pid=1910
>     3 comm="httpd"
>     path=2F6465762F73686D2F6666694F337A6B4972202864656C6574656429 dev
>     =tmpfs ino=1281359 scontext=unconfined_u:system_r:httpd_t:s0
>     tcontext=unconfined
>     _u:object_r:httpd_tmpfs_t:s0 tclass=file
>
>     And are a little clearer if you use
>
>      sudo ausearch -i | grep denied
>
>     type=AVC msg=audit(04/19/2012 14:36:07.213:5184) : avc:  denied  {
>     execute } for  pid=19103 comm=httpd path=/dev/shm/ffiO3zkIr
>     (deleted) dev=tmpfs ino=1281359
>     scontext=unconfined_u:system_r:httpd_t:s0
>     tcontext=unconfined_u:object_r:httpd_tmpfs_t:s0 tclass=file
>
>     Something in HTTPD is trying to generate code and then execute it
>     by writing to a file.  We've traced that something down to the
>     UUID generation code.  The standard UUID module makes a ctypes
>     call, which does run time generation of Native stubs  in order to
>     call into libuuid to actually generate the UUID.
>
>     While we are working with the Python maintainers to come up with
>     long term fixes,  we probably want to come up with something short
>     term.  We are going to generate an alternative UUID module,
>      probably named something along the lines of uuid_no_ctypes,  that
>     will call into libuuid via pregenerated function stubs.  This
>     module will be a copy of the uuid.py file from The upstream, with
>     the absolute minimum of changes to avoid ctypes.
>
>     Once we've got this working,  all of the projects that use UUID
>     should switch over...this is a good argument for putting that code
>     into Openstack-common.  Keystone, Nova, and Quantum all import uuid.
>
>     None of the projects seem to be using ctypes directly.  However,
>      it is possible that we are using other third party libraries
>     that, in turn, use ctypes.
>
>     _______________________________________________
>     Mailing list: https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     Post to     : openstack at lists.launchpad.net
>     <mailto:openstack at lists.launchpad.net>
>     Unsubscribe : https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     More help   : https://help.launchpad.net/ListHelp
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120422/5a15907d/attachment.html>