Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1151568 - libffi: should open NX bypass descriptor with O_CLOEXEC
libffi: should open NX bypass descriptor with O_CLOEXEC
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libffi (Show other bugs)
7.0
x86_64 Linux
unspecified Severity low
: rc
: ---
Assigned To: Andrew Haley
Michael Petlan
:
Depends On:
Blocks: 1297579 1313485
  Show dependency treegraph
 
Reported: 2014-10-10 13:30 EDT by Tomasz Konefal
Modified: 2016-11-04 01:04 EDT (History)
10 users (show)

See Also:
Fixed In Version: libffi-3.0.13-18.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-04 01:04:33 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2385 normal SHIPPED_LIVE libffi bug fix update 2016-11-03 09:53:20 EDT

  None (edit)
Description Tomasz Konefal 2014-10-10 13:30:05 EDT
Description of problem:

sealert -l 9864c067-b7e7-406e-8e7c-2bf895c667be
SELinux is preventing /usr/sbin/xtables-multi from 'read, write' accesses on the file .

*****  Plugin leaks (86.2 confidence) suggests   *****************************

If you want to ignore xtables-multi trying to read write access the  file, because you believe it should not need this access.
Then you should report this as a bug.
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/sbin/xtables-multi /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests   **************************

If you believe that xtables-multi should be allowed read write access on the  file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep iptables /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:iptables_t:s0
Target Context                system_u:object_r:firewalld_tmpfs_t:s0
Target Objects                 [ file ]
Source                        iptables
Source Path                   /usr/sbin/xtables-multi
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           iptables-1.4.21-13.el7.x86_64
Target RPM Packages
Policy RPM                    selinux-policy-3.12.1-153.el7_0.11.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed)
                              3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Aug 11
                              13:37:49 EDT 2014 x86_64 x86_64
Alert Count                   48
First Seen                    2014-09-19 15:36:04 PDT
Last Seen                     2014-10-10 10:04:04 PDT
Local ID                      9864c067-b7e7-406e-8e7c-2bf895c667be

Raw Audit Messages
type=AVC msg=audit(1412960644.974:505): avc:  denied  { read write } for  pid=1511 comm="ip6tables" path=2F6465762F73686D2F66666975614B66677A202864656C6574656429 dev="tmpfs" ino=20273 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:firewalld_tmpfs_t:s0 tclass=file


type=SYSCALL msg=audit(1412960644.974:505): arch=x86_64 syscall=execve success=yes exit=0 a0=12ec710 a1=12eded0 a2=146a840 a3=7fffe1b0bba0 items=2 ppid=830 pid=1511 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=ip6tables exe=/usr/sbin/xtables-multi subj=system_u:system_r:iptables_t:s0 key=(null)

type=CWD msg=audit(1412960644.974:505): cwd=/

type=PATH msg=audit(1412960644.974:505): item=0 name=/sbin/ip6tables inode=16992821 dev=fd:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:iptables_exec_t:s0 objtype=NORMAL

type=PATH msg=audit(1412960644.974:505): item=1 name=(null) inode=1988 dev=fd:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 objtype=NORMAL

Hash: iptables,iptables_t,firewalld_tmpfs_t,file,read,write


Additional info:
Not sure if this is relevant, but I have applied the CIS recommendations (v1.0) for RHEL7. In particular, there is a suggestion of tmpfs being involved.

# mount | grep tmpfs
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=498208k,nr_inodes=124552,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,seclabel,mode=755)
none on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel)
Comment 3 Miroslav Grepl 2015-04-27 10:18:36 EDT
This is a leak coming for firewalld.
Comment 4 Florian Weimer 2015-06-30 11:03:17 EDT
>>> base64.b16decode("2F6465762F73686D2F66666975614B66677A202864656C6574656429")
'/dev/shm/ffiuaKfgz (deleted)'

This is likely the NX bypass from libffi.  firewalld probably uses libffi-generated proxies for girepository access.

For background on the NX bypass with page aliasing, see <http://www.akkadia.org/drepper/selinux-mem.html> (last section).
Comment 5 Florian Weimer 2015-06-30 11:09:21 EDT
This is a libffi bug:

/* Open a temporary file name, and immediately unlink it.  */
static int
open_temp_exec_file_name (char *name)
{
  int fd = mkstemp (name);

  if (fd != -1)
    unlink (name);

  return fd;
}

It should use mkostemp with O_CLOEXEC.
Comment 6 Florian Weimer 2015-08-24 15:30:29 EDT
Already fixed upstream:

https://github.com/atgreen/libffi/commit/8daeed9570af72eb135c8ded460d2888f05b2e68
Comment 7 Deepak Bhole 2016-02-02 15:39:38 EST
Already fixed upstream. Acking.
Comment 14 Michael Petlan 2016-06-24 07:45:11 EDT
Reproduced with libffi-3.0.13-16.el7 and passed with libffi-3.0.13-18.el7.

VERIFIED.
Comment 16 errata-xmlrpc 2016-11-04 01:04:33 EDT
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.

https://rhn.redhat.com/errata/RHBA-2016-2385.html

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