openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Sun, Apr 22, 2012 at 1:49 PM, Adam Young <ayoung@xxxxxxxxxx> wrote:

>  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?
>

No, I haven't, but I can try in the next day or two. Are the steps to
reproduce the problem documented somewhere?

If you need to "hide" ctypes, the dashboard code can also insert a None
value into sys.modules to prevent it from being imported. Something like
this should do the trick:

import sys
sys.modules['ctypes'] = None


>
>
>
> On Thu, Apr 19, 2012 at 11:53 AM, Adam Young <ayoung@xxxxxxxxxx> 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
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>