This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 814391 - UUID package cause SELinux AVC Denials
UUID package cause SELinux AVC Denials
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python (Show other bugs)
6.2
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Dave Malcolm
Petr Šplíchal
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-19 14:37 EDT by Adam Young
Modified: 2016-05-31 21:47 EDT (History)
3 users (show)

See Also:
Fixed In Version: python-2.6.6-35.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 05:31:45 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Adam Young 2012-04-19 14:37:54 EDT
Description of problem:

CTypes does run time code generation.  HTTPD does not and should not allow this.  The core Python 2.6 UUID  module uses CTypes to call into libuuid.  This triggers an SELinux AVC Denial.

Version-Release number of selected component (if applicable):


How reproducible:

100%

Steps to Reproduce:
1.  Create a file /var/www/cgi-bin/uuid with the contents

import sys
import uuid

def application(environ, start_response):
    status = '200 OK'
    response_headers = [('Content-type', 'text/plain')]
    start_response(status, response_headers)
    return ['Testing UUID\n']



2.  Create a file /etc/httpd/conf.d/uuid.conf with the contents
WSGIScriptAlias /uuid  /var/www/cgi-bin/uuid


3.  Ensure SELinux is enabled:
[ayoung@dhcp47-42 cgi-bin]$ getenforce 
Enforcing

4. Restart HTTPD
   sudo service httpd restart

5.   wget http://localhost/uuid


Actual results:

IN  /var/log/audit/audit.log  The following denials appear

type=SYSCALL msg=audit(1334860233.593:5166): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=1000 a2=5 a3=1 items=0 ppid=18500 pid=18514 auid=501 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=11 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=MMAP msg=audit(1334860233.593:5166): fd=16 flags=0x1
type=AVC msg=audit(1334860233.593:5167): avc:  denied  { execute } for  pid=18514 comm="httpd" path=2F7661722F746D702F666669343644485554202864656C6574656429 dev=dm-0 ino=919311 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_tmp_t:s0 tclass=file
type=SYSCALL msg=audit(1334860233.593:5167): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=1000 a2=5 a3=1 items=0 ppid=18500 pid=18514 auid=501 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=11 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=MMAP msg=audit(1334860233.593:5167): fd=16 flags=0x1
type=AVC msg=audit(1334860233.593:5168): avc:  denied  { execute } for  pid=18514 comm="httpd" path=2F6465762F73686D2F666669393668696C38202864656C6574656429 dev=tmpfs ino=1279178 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_tmpfs_t:s0 tclass=file
type=SYSCALL msg=audit(1334860233.593:5168): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=1000 a2=5 a3=1 items=0 ppid=18500 pid=18514 auid=501 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=11 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=MMAP msg=audit(1334860233.593:5168): fd=16 flags=0x1


Expected results:

No AVC denial messages in Audit log


Additional info:
Comment 2 Dave Malcolm 2012-04-20 14:19:45 EDT
This is related to (but different from) bug 582009

Within ctypes, objects of _ctypes.CThunkObject wrap machine code "thunks", containing run-time generated machine code hooks for bridging between Python callables and C functions.  Instantiating one of these objects requires an allocation of a page of RAM that can be both written to and executed.  In RHEL's python we patch ctypes to use libffi's ffi_closure_alloc for this, which uses a trick involving mapping a tempfile in /tmp multiple times to avoid SELinux's complaining about pages of memory being both writable and executable.

This fails for httpd when the SELinux boolean httpd_tmp_exec is off.  As noted in bug 582009, one workaround is:
  setsebool httpd_tmp_exec on
which allows httpd to execute such mapped tempfiles - but which could be a security issue.

uuid doesn't need to use much ctypes, and indeed, it could be rewritten using a C extension module to avoid the use of ctypes altogether.

It turns out that merely doing an "import ctypes" allocates a thunk, but this is somewhat spurious.  Within /usr/lib64/python2.7/ctypes/__init__.py in _reset_cache there is this code:
    # XXX for whatever reasons, creating the first instance of a callback
    # function is needed for the unittests on Win64 to succeed.  This MAY
    # be a compiler bug, since the problem occurs only when _ctypes is
    # compiled with the MS SDK compiler.  Or an uninitialized variable?
    CFUNCTYPE(c_int)(lambda: None)

If I comment out that line, then a mere "import ctypes" doesn't need to allocate any thunks (PyCFuncPtr_new uses the GenericPyCData_new clause for a single int/long argument, withouth reaching the thunk allocator).

Similarly, without this line, I am able to run the test.test_uuid test suite without Python attempting to allocate any thunks.  I am also still able to run the test.test_ctypes test suite (although that does allocate thunks).

I see at https://www.redhat.com/archives/epel-devel-list/2012-April/msg00054.html that people are running into this with Django.  Can you confirm that Django still works if you comment out the line mentioned above?
Comment 3 Dave Malcolm 2012-04-20 14:36:35 EDT
Looks like I've independently reinvented the fix mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=582009#c1
Comment 4 Dave Malcolm 2012-04-20 15:06:00 EDT
Downstream removal of that line committed to python "master" for Fedora 18:
http://pkgs.fedoraproject.org/gitweb/?p=python.git;a=commitdiff;h=7461fe5163d36a83893db6a696f5cc6a74cb6b51

Building python-2.7.3-4.fc18 for dist-rawhide
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=4009760
Comment 5 Dave Malcolm 2012-04-20 15:31:04 EDT
Similarly for "python3" in Fedora 18:
http://pkgs.fedoraproject.org/gitweb/?p=python3.git;a=commitdiff;h=8a28107df1670a03a12cf6a7787160f103d8d8c8


Building python3-3.2.3-4.fc18 for dist-rawhide
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=4009802
Comment 10 Dave Malcolm 2012-05-02 15:11:46 EDT
Within Fedora:

  * this is fixed in rawhide as of python-2.7.3-4.fc18 and python-3.2.3-4.fc18

  * candidate fix for python in F17:
    https://admin.fedoraproject.org/updates/FEDORA-2012-7019/python-2.7.3-6.fc17

  * candidate fix for python3 in F17:
    https://admin.fedoraproject.org/updates/FEDORA-2012-5785/python3-3.2.3-5.fc17
Comment 11 Suzanne Yeghiayan 2012-05-14 15:03:31 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 16 RHEL Product and Program Management 2012-10-09 15:11:39 EDT
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.
Comment 21 errata-xmlrpc 2013-02-21 05:31:45 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0437.html

Note You need to log in before you can comment on or make changes to this bug.