gssproxy reads the links at /proc/<pid>/exe to perform program name matching for purposes of access control. (See the get_program() function: https://pagure.io/gssproxy/blob/master/f/src/gp_socket.c#_283 ) However, this doesn't work - selinux blocks the realpath() call. Combined, it looks something like this: May 3 16:39:42 master audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=httpd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' May 3 16:40:07 master audit[728]: AVC avc: denied { sys_ptrace } for pid=728 comm="gssproxy" capability=19 scontext=system_u:system_r:gssproxy_t:s0 tcontext=system_u:system_r:gssproxy_t:s0 tclass=capability permissive=0 May 3 16:40:07 master gssproxy[704]: gssproxy[728]: Unexpected failure in realpath: 13 (Permission denied) May 3 16:40:07 master audit[728]: AVC avc: denied { sys_ptrace } for pid=728 comm="gssproxy" capability=19 scontext=system_u:system_r:gssproxy_t:s0 tcontext=system_u:system_r:gssproxy_t:s0 tclass=capability permissive=0 May 3 16:40:07 master gssproxy[704]: gssproxy[728]: Unexpected failure in realpath: 13 (Permission denied) May 3 16:40:07 master audit[728]: AVC avc: denied { sys_ptrace } for pid=728 comm="gssproxy" capability=19 scontext=system_u:system_r:gssproxy_t:s0 tcontext=system_u:system_r:gssproxy_t:s0 tclass=capability permissive=0 May 3 16:40:07 master gssproxy[704]: gssproxy[728]: Unexpected failure in realpath: 13 (Permission denied) May 3 16:42:48 master audit[728]: AVC avc: denied { sys_ptrace } for pid=728 comm="gssproxy" capability=19 scontext=system_u:system_r:gssproxy_t:s0 tcontext=system_u:system_r:gssproxy_t:s0 tclass=capability permissive=0 May 3 16:42:48 master gssproxy[704]: gssproxy[728]: Unexpected failure in realpath: 13 (Permission denied) The failure is confusing because this isn't clearly related to ptrace(). However, per proc(5): Permission to dereference or read (readlink(2)) this symbolic link is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2). So I believe granting gssproxy this capability should make the AVCs go away, and make our program name matching work. Thanks!
*** Bug 1575236 has been marked as a duplicate of this bug. ***
selinux-policy-3.14.1-29.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a74875b364
selinux-policy-3.14.1-29.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-a74875b364
selinux-policy-3.14.1-29.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.