+++ This bug was initially created as a clone of Bug #1379278 +++

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

--- Additional comment from Lukas Slebodnik on 2016-09-26 05:22:09 EDT ---

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

--- Additional comment from Lukas Slebodnik on 2016-09-26 05:28:21 EDT ---

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

--- Additional comment from Lukas Slebodnik on 2016-09-26 05:31:07 EDT ---

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.

--- Additional comment from Jakub Hrozek on 2016-09-26 05:40:48 EDT ---

(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?

--- Additional comment from Lukas Slebodnik on 2016-09-26 05:51:38 EDT ---

(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.

--- Additional comment from Simo Sorce on 2016-09-26 16:26:26 EDT ---

It may make sense to allow only sssd-secrets to access the /var/lib/sss/secrets path.

Simo.

--- Additional comment from Daniel Walsh on 2016-09-27 08:52:15 EDT ---

Simplest thing is to label sssd-secrets as sssd_exec_t.

--- Additional comment from Fedora Admin XMLRPC Client on 2016-09-27 11:15:47 EDT ---

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

--- Additional comment from Lukas Slebodnik on 2016-12-12 07:53:09 EST ---

(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

--- Additional comment from Daniel Walsh on 2016-12-14 11:42:52 EST ---

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.

--- Additional comment from Daniel Walsh on 2016-12-14 11:46:01 EST ---

secrets.socket should be labeled sssd_var_run_t.

--- Additional comment from Daniel Walsh on 2017-04-19 16:14:36 EDT ---

Lukas can you add this default labeling.

--- Additional comment from Lukas Slebodnik on 2017-04-19 16:53:35 EDT ---

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

--- Additional comment from Lukas Slebodnik on 2017-04-20 07:49:09 EDT ---

It should be following commits from selinux-policy-contrib (rawhide branch)

* f56e010f134650ba0bd6344cb93c9a76eaeda033
* ded6d59f1a3a99cb080c186df74bd67601c9d835
* feb2c86bd3a0f9164725f9dd3de2332406bb1ad4