Description of problem: systemctl start sssd-secrets.socket SELinux is preventing systemd from 'create' accesses on the unix_stream_socket Unknown. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd should be allowed create access on the Unknown unix_stream_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'systemd' --raw | audit2allow -M my-systemd # semodule -X 300 -i my-systemd.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context system_u:system_r:unconfined_service_t:s0 Target Objects Unknown [ unix_stream_socket ] Source systemd Source Path systemd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-215.fc25.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 4.8.0-0.rc6.git0.1.fc25.x86_64 #1 SMP Mon Sep 12 19:16:54 UTC 2016 x86_64 x86_64 Alert Count 1 First Seen 2016-09-26 11:15:52 CEST Last Seen 2016-09-26 11:15:52 CEST Local ID 5d5352f2-5843-4c00-8907-79b0a0925485 Raw Audit Messages type=AVC msg=audit(1474881352.999:654): 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=1 Hash: systemd,init_t,unconfined_service_t,unix_stream_socket,create Version-Release number of selected component: selinux-policy-3.13.1-215.fc25.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.8.0-0.rc6.git0.1.fc25.x86_64 type: libreport Potential duplicate: bug 1291940
AVC in enforcing mode: type=AVC msg=audit(09/26/2016 11:15:02.161:650) : 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 AVCs in permissive mode: type=AVC msg=audit(09/26/2016 11:15:52.999:654) : 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=1 ---- type=AVC msg=audit(09/26/2016 11:15:52.999:655) : avc: denied { setopt } 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=1 ---- type=AVC msg=audit(09/26/2016 11:15:52.999:656) : avc: denied { bind } 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=1 ---- type=AVC msg=audit(09/26/2016 11:15:52.999:657) : avc: denied { listen } for pid=1 comm=systemd path=/run/secrets.socket scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=1
sssd-1.14+ has a new socket activated service sssd-secrets.service (sssd-secrets.socket) But this new service is running with unconfined_service_t sh# systemctl status sssd-secrets.service ● sssd-secrets.service - SSSD Secrets Service responder Loaded: loaded (/usr/lib/systemd/system/sssd-secrets.service; indirect; vendor preset: disabled) Active: inactive (dead) since Mon 2016-09-26 11:25:34 CEST; 10s ago Process: 7002 ExecStart=/usr/libexec/sssd/sssd_secrets --uid 0 --gid 0 --debug-to-files (code=exited, status=0/SUCCESS) Main PID: 7002 (code=exited, status=0/SUCCESS) Sep 26 11:16:18 host.example.com systemd[1]: Started SSSD Secrets Service responder. Sep 26 11:16:18 host.example.com sssd[secrets][7002]: Starting up Sep 26 11:25:34 host.example.com systemd[1]: Stopping SSSD Secrets Service responder... Sep 26 11:25:34 host.example.com systemd[1]: Stopped SSSD Secrets Service responder. sh# curl -H "Content-Type: application/json" -XGET --unix-socket /var/run/secrets.socket http://localhost/secrets/foo <html> <head> <title>404 Not Found</title></head> <body> <h1>Not Found</h1> <p>The requested resource was not found.</p> </body> sh# systemctl status sssd-secrets.service ● sssd-secrets.service - SSSD Secrets Service responder Loaded: loaded (/usr/lib/systemd/system/sssd-secrets.service; indirect; vendor preset: disabled) Active: active (running) since Mon 2016-09-26 11:25:57 CEST; 7s ago Main PID: 7197 (sssd_secrets) Tasks: 1 (limit: 4915) Memory: 1.3M CPU: 11ms CGroup: /system.slice/sssd-secrets.service └─7197 /usr/libexec/sssd/sssd_secrets --uid 0 --gid 0 --debug-to-files Sep 26 11:25:57 host.example.com systemd[1]: Started SSSD Secrets Service responder. Sep 26 11:25:57 host.example.com sssd[secrets][7197]: Starting up sh# ps auxfZ | grep unconfined_service_[t] system_u:system_r:unconfined_service_t:s0 root 7197 0.0 0.0 247644 7172 ? Ss 11:25 0:00 /usr/libexec/sssd/sssd_secrets --uid 0 --gid 0 --debug-to-files
I forgot to mention that the sssd-secrets.service shares configuration with sssd (/etc/sssd/sssd.conf) and few others things. Adding jhrozek and simo to CC in case of more questions.
(In reply to Lukas Slebodnik from comment #3) > I forgot to mention that the sssd-secrets.service shares configuration with > sssd (/etc/sssd/sssd.conf) and few others things. Yes, but the service doesn't create the configuration, just reads it. btw should we also clone this bug to RHEL because the same problem also exists there?
(In reply to Jakub Hrozek from comment #4) > (In reply to Lukas Slebodnik from comment #3) > > I forgot to mention that the sssd-secrets.service shares configuration with > > sssd (/etc/sssd/sssd.conf) and few others things. > > Yes, but the service doesn't create the configuration, just reads it. > Actually it does not read /etc/sssd/sssd.conf but /var/lib/sss/db/config.ldb and need to have read/write access to the directory /var/lib/sss/secrets/ But both has the same SElinux file context sh# matchpathcon /var/lib/sss/db/config.ldb /var/lib/sss/secrets/ /var/lib/sss/db/config.ldb system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/secrets system_u:object_r:sssd_var_lib_t:s0 I think we needn't to separate sssd.service and sssd-secrets.service.
It may make sense to allow only sssd-secrets to access the /var/lib/sss/secrets path. Simo.
Simplest thing is to label sssd-secrets as sssd_exec_t.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
(In reply to Daniel Walsh from comment #7) > Simplest thing is to label sssd-secrets as sssd_exec_t. It is not enough in my testing. We need to also change the label for unix socket used for socket activation. Following change works for me sh# chcon system_u:object_r:sssd_var_lib_t:s0 /var/run/secrets.socket sh# chcon system_u:object_r:sssd_exec_t:s0 /usr/libexec/sssd/sssd_secrets I tried unix socket with sssd_var_lib_t because other sssdd unix sockets have such type. sh# matchpathcon /var/lib/sss/pipes/* /var/lib/sss/pipes/nss system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/pipes/pam system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/pipes/private system_u:object_r:sssd_var_lib_t:s0
Looks like secrets.socket does not have a default label. We need to get that labeled as well and have a file name transition rule so that init will create it with the correct label.
secrets.socket should be labeled sssd_var_run_t.
Lukas can you add this default labeling.
It is fixed in fedora26. It just need to be backported sh$ rpm -q selinux-policy-targeted selinux-policy-targeted-3.13.1-250.fc26.noarch sh$ matchpathcon /var/run/secrets.socket /var/run/secrets.socket system_u:object_r:sssd_var_run_t:s0
It should be following commits from selinux-policy-contrib (rawhide branch) * f56e010f134650ba0bd6344cb93c9a76eaeda033 * ded6d59f1a3a99cb080c186df74bd67601c9d835 * feb2c86bd3a0f9164725f9dd3de2332406bb1ad4
*** Bug 1459076 has been marked as a duplicate of this bug. ***