Bug 1411981

To clarify: This occurs on the RHOSP Director [Undercloud] system

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)

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 0.0.0.0 -U 11211 -t 8 >> /var/log/memcached.log 2>&1

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

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

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.

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 :-)

Thom,

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.

Per https://bugzilla.redhat.com/show_bug.cgi?id=1411981#c10, moving to RHOSP.

Is this resulting in a functional issue (memcached not running, etc.)?

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

The result is memcached still runs in init_t, not memcached_t

OK, thanks.

Hmm.

[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 127.0.0.1,::1

So, whatever is broken is a regression in memcached.

Not fixed by simple rebase; digging deeper.

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.

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.

Other services in RHEL 7.3 which use this directive also end up running as init_t.

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 127.0.0.1,::1

Haikel, this patch may be suitable for RDO but not upstream.

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://access.redhat.com/errata/RHEA-2017:1245