Bug 1416318 - Update SELinux policy for SSSD as the responders may be socket-activated (for Fedora 25+)
Update SELinux policy for SSSD as the responders may be socket-activated (for...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
25
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lukas Vrabec
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-01-25 04:37 EST by Fabiano Fidêncio
Modified: 2017-07-04 04:02 EDT (History)
9 users (show)

See Also:
Fixed In Version: selinux-policy-3.13.1-225.12
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-04 04:02:59 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)

  None (edit)
Description Fabiano Fidêncio 2017-01-25 04:37:07 EST
Due to this new feature add to SSSD I've been hitting the following AVCs:

Jan 25 09:25:57 client1.ipa.example sssd_be[14440]: GSSAPI client step 1
Jan 25 09:25:57 client1.ipa.example sssd_be[14440]: GSSAPI client step 1
Jan 25 09:25:57 client1.ipa.example sssd_be[14440]: GSSAPI client step 1
Jan 25 09:25:57 client1.ipa.example sssd_be[14440]: GSSAPI client step 2
Jan 25 09:26:04 client1.ipa.example audit[1]: AVC avc:  denied  { create } for  pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
Jan 25 09:26:04 client1.ipa.example systemd[1]: sssd-pam.socket: Failed to listen on sockets: Permission denied
Jan 25 09:26:05 client1.ipa.example systemd[1]: Failed to listen on SSSD PAM Service responder socket.
-- Subject: Unit sssd-pam.socket has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit sssd-pam.socket has failed.
-- 
-- The result is failed.

Jan 25 09:26:04 client1.ipa.example audit[1]: AVC avc:  denied  { create } for  pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
Jan 25 09:26:05 client1.ipa.example systemd[1]: sssd-autofs.socket: Failed to listen on sockets: Permission denied
Jan 25 09:26:05 client1.ipa.example systemd[1]: Failed to listen on SSSD AutoFS Service responder socket.
-- Subject: Unit sssd-autofs.socket has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit sssd-autofs.socket has failed.
-- 
-- The result is failed.

As far as I understand it's going to happen for every added sssd-@responder@.socket, and here's the complete list:
- sssd-autofs.socket
- sssd-nss.socket
- sssd-pac.socket
- sssd-pam.socket
- sssd-pam-priv.socket
- sssd-ssh.socket
- sssd-sudo.socket

I'm not sure if something has to be done for the services as well.

Anyways, Let me know any other info is needed.
Comment 1 Lukas Slebodnik 2017-03-16 06:59:02 EDT
A little bit more details for this BZ.
Previous /usr/sbin/sssd fork+exec sssd responders (sssd_nss, sssd_pam ...)
It was configured in sssd.conf which responders will be started.
in sssd-1.15 we added possibility to start responders as socket activated services. There sore there are few AVCs

Firstly after starting some socket by systemctl. Because previously sockets were created by sssd responders which were already in sssd_t domain.

e.g.
sh# systemctl start sssd-pam.socket
sh# ausearch -m avc
----
time->Thu Mar 16 11:44:12 2017
type=AVC msg=audit(1489661052.387:10581): avc:  denied  { unlink } for  pid=1 comm="systemd" name="pam" dev="dm-0" ino=270594 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=sock_file permissive=1
----
time->Thu Mar 16 11:44:12 2017
type=AVC msg=audit(1489661052.387:10582): avc:  denied  { create } for  pid=1 comm="systemd" name="pam" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=sock_file permissive=1
----
time->Thu Mar 16 11:44:12 2017
type=AVC msg=audit(1489661052.388:10583): avc:  denied  { setattr } for  pid=8128 comm="systemd" name="pam" dev="dm-0" ino=270594 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=sock_file permissive=1 



Another issue is that socket activated responders are running with unconfined_service_t SELinux context

sh# ps auxZ | grep sssd_pa[m]
system_u:system_r:unconfined_service_t:s0 sssd 8244 0.0  0.2 138724 8420 ?     Ss   11:52   0:00 /usr/libexec/sssd/sssd_pam --debug-to-files --socket-activated


sh# ps auxZ | grep sss[d]
system_u:system_r:sssd_t:s0     root      8209  0.0  0.2 161820  8632 ?        Ss   11:50   0:00 /usr/sbin/sssd -i -f
system_u:system_r:sssd_t:s0     sssd      8210  0.0  0.4 197152 12724 ?        S    11:50   0:00 /usr/libexec/sssd/sssd_be --domain redhat.com --uid 995 --gid 993 --debug-to-files
system_u:system_r:sssd_t:s0     sssd      8211  0.0  1.0 159000 32568 ?        S    11:50   0:00 /usr/libexec/sssd/sssd_nss --uid 995 --gid 993 --debug-to-files
system_u:system_r:unconfined_service_t:s0 sssd 8244 0.0  0.2 138724 8420 ?     Ss   11:52   0:00 /usr/libexec/sssd/sssd_pam --debug-to-files --socket-activated





Last but not least is that sssd still support both ways of starting responders.
Both ways need to work with SELinux enforcing mode.

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