<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 22, 2012 at 1:49 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div class="im">
    On 04/20/2012 11:51 AM, Doug Hellmann wrote:
    <blockquote type="cite">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.<br>
    </blockquote>
    <br></div>
    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?</div></blockquote><div><br></div><div>No, I haven't, but I can try in the next day or two. Are the steps to reproduce the problem documented somewhere?</div>
<div><br></div><div>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:</div><div><br></div>
<div>import sys</div><div>sys.modules['ctypes'] = None</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="im">
<br>
    <br>
    <blockquote type="cite">
      <br>
      <div class="gmail_quote">On Thu, Apr 19, 2012 at 11:53 AM, Adam
        Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          Did a little digging into an audit log message we've been
          seeing specifically on Dashboard.<br>
          <br>
          They look like this in audit.log<br>
          <br>
          type=AVC msg=audit(1334860567.213:5184): avc:  denied  {
          execute } for  pid=1910<br>
          3 comm="httpd" path=2F6465762F73686D2F6666694F337A6B4972202864656C6574656429
          dev<br>
          =tmpfs ino=1281359 scontext=unconfined_u:system_r:httpd_t:s0
          tcontext=unconfined<br>
          _u:object_r:httpd_tmpfs_t:s0 tclass=file<br>
          <br>
          And are a little clearer if you use<br>
          <br>
           sudo ausearch -i | grep denied<br>
          <br>
          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<br>
          <br>
          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.<br>
          <br>
          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.<br>
          <br>
          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.<br>
          <br>
          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.<br>
          <br>
          _______________________________________________<br>
          Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
          Post to     : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
          Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
          More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </div></div>

</blockquote></div><br></div>