On Sun, Apr 22, 2012 at 1:49 PM, Adam Young <ayo...@redhat.com> 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 <ayo...@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 >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> > > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp