Bug 1411981 - [SELinux] security_bounded_transition error
Summary: [SELinux] security_bounded_transition error
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: memcached
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 11.0 (Ocata)
Assignee: Lon Hohberger
QA Contact: Thom Carlin
Depends On:
Blocks: 1454388
TreeView+ depends on / blocked
Reported: 2017-01-10 22:17 UTC by Thom Carlin
Modified: 2017-05-22 15:21 UTC (History)
13 users (show)

Fixed In Version: memcached-1.4.33-3.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1454388 (view as bug list)
Last Closed: 2017-05-17 19:56:18 UTC
Target Upstream Version:

Attachments (Terms of Use)
Drop NoNewPrivileges since it breaks transitioning out of init_t (1.01 KB, patch)
2017-03-10 19:29 UTC, Lon Hohberger
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1245 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 11.0 Bug Fix and Enhancement Advisory 2017-05-17 23:01:50 UTC

Description Thom Carlin 2017-01-10 22:17:09 UTC
Description of problem:

During QCI 1.1 RPM installation, error in audit logs

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


How reproducible:


Steps to Reproduce:
1. Install QCI 1.1 upto launch-fusor-undercloud-installer completing
2. grep -i denied /var/log/audit/audit.log

Actual results:

type=SELINUX_ERR msg=audit(<numbers>): op=security_bounded_transition seresult=denied oldcontext=system_u:system_r:init_t:s0 newcontext=system_u:system_r:memcached_t:s0

Expected results:

No errors

Additional info:

Seems to happen every time memcached is restarted

Comment 2 Thom Carlin 2017-01-10 22:19:33 UTC
To clarify: This occurs on the RHOSP Director [Undercloud] system

Comment 3 Thom Carlin 2017-01-10 22:34:42 UTC
related result:
type=SYSCALL msg=audit(<same_numbers>): arch=c000003e syscall=59 success=yes exit=0 a0=7f7a0109ee40 a1=7f7a00f5d970 a2=7f7a00f16b90 a3=fffffc00 items=0 ppid=1 pid=6121 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="memcached" exe="/usr/bin/memcached" subj=system_u:system_r:init_t:s0 key=(null)

Comment 4 Thom Carlin 2017-01-10 22:37:56 UTC
ps --context 6121
  PID CONTEXT                         COMMAND
 6121 system_u:system_r:init_t:s0     /usr/bin/memcached -p 11211 -u memcached -m 60935 -c 8192 -l -U 11211 -t 8 >> /var/log/memcached.log 2>&1

NOTE: /var/log/memcached.log does not exist

Comment 5 Thom Carlin 2017-01-12 13:37:26 UTC
From internal discussions:
* syscall 59 is execve.  The application is leaking fds (see https://docs.fedoraproject.org/en-US/Fedora_Security_Team/1/html/Defensive_Coding/sect-Defensive_Coding-Tasks-Descriptors-Child_Processes.html)
* Appears to be due to setcon(3) failing
* Expected transition: init_t @ memcached_exec_t --> memcached_t

jmatthews: Should the execve issue be a separate bz?
jmatthews: Should this be reassigned to RHEL/selinux-policy?

I've uploaded the audit.log as a private attachment

Comment 7 Jason Montleon 2017-01-12 13:43:30 UTC
If this is memcached should this not be filed against OpenStack? All fusor-undercloud-installer is doing is collecting parameters and invoking the instack-uncloud-installer.

Comment 9 Thom Carlin 2017-01-12 14:16:07 UTC
Some noise in the log is due to https://bugzilla.redhat.com/show_bug.cgi?id=1195330

Additional information:
systemd is trying to:
* launch memcached with a different security context
* At the same time trying to grant it execute permissions on the same shared memory segment

More likely an issue with either fusor-undercloud-installer or the hand off to instack-uncloud-installer

If you add a typebounds statement then memcached will have authorization similar/equal to systemd but don't believe this is desired :-)

Comment 10 John Matthews 2017-01-13 15:39:46 UTC

After reviewing the information present we do not believe the issue is related to fusor-undercloud-installer.

We believe this an issue to address inside of the undercloud or perhaps RHEL component.

Please reassign to the component you feel is appropriate.

Comment 11 Thom Carlin 2017-01-13 16:01:03 UTC
Per https://bugzilla.redhat.com/show_bug.cgi?id=1411981#c10, moving to RHOSP.

Comment 12 Lon Hohberger 2017-02-20 20:02:44 UTC
Is this resulting in a functional issue (memcached not running, etc.)?

Generally, we're looking for type=AVC, not type=SELINUX_ERR

Comment 13 Thom Carlin 2017-02-20 20:22:12 UTC
The result is memcached still runs in init_t, not memcached_t

Comment 14 Lon Hohberger 2017-02-21 16:41:51 UTC
OK, thanks.

Comment 15 Lon Hohberger 2017-03-10 18:37:41 UTC

[root@localhost ~]# ps -auwwxZ | grep memcache
system_u:system_r:memcached_t:s0 memcach+ 20247 0.0  0.0 325556  1156 ?        Ssl  13:30   0:00 /usr/bin/memcached -u memcached -p 11211 -m 64 -c 1024

This is with the RHEL 7.3.z version.

With the OSP10 version:

[root@localhost ~]# ps -auwwxZ | grep memcache
system_u:system_r:init_t:s0     memcach+ 20377  1.0  0.0 333840  1184 ?        Ssl  13:36   0:00 /usr/bin/memcached -p 11211 -u memcached -m 64 -c 1024 -l,::1

So, whatever is broken is a regression in memcached.

Comment 17 Lon Hohberger 2017-03-10 19:01:47 UTC
Not fixed by simple rebase; digging deeper.

Comment 18 Lon Hohberger 2017-03-10 19:23:26 UTC
The NoNewPrivileges= directive in the systemd unit (not present in the RHEL 7.3 version, but added in the OSP version) is breaking this.

Apparently, it works a little too well.

Comment 19 Lon Hohberger 2017-03-10 19:29:27 UTC
Created attachment 1262045 [details]
Drop NoNewPrivileges since it breaks transitioning out of init_t

It's likely this isn't suitable for general upstream use.

Comment 20 Lon Hohberger 2017-03-10 19:42:02 UTC
Other services in RHEL 7.3 which use this directive also end up running as init_t.

Comment 22 Lon Hohberger 2017-03-10 20:18:19 UTC
With patch to drop NoNewPrivileges:

system_u:system_r:memcached_t:s0 memcach+ 22589 0.4  0.0 333840  1184 ?        Ssl  15:17   0:00 /usr/bin/memcached -p 11211 -u memcached -m 64 -c 1024 -l,::1

Comment 24 Lon Hohberger 2017-03-10 20:19:56 UTC
Haikel, this patch may be suitable for RDO but not upstream.

Comment 28 errata-xmlrpc 2017-05-17 19:56:18 UTC
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.


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