Description of problem: During QCI 1.1 RPM installation, error in audit logs Version-Release number of selected component (if applicable): 1.1 How reproducible: 100% 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
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