RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1448060 - sssd-kcm should not run as unconfined_service_t
Summary: sssd-kcm should not run as unconfined_service_t
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.4
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On: 1447411
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-04 13:03 UTC by Lukas Slebodnik
Modified: 2017-08-01 15:26 UTC (History)
11 users (show)

Fixed In Version: selinux-policy-3.13.1-151.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1447411
Environment:
Last Closed: 2017-08-01 15:26:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:1861 0 normal SHIPPED_LIVE selinux-policy bug fix update 2017-08-01 17:50:24 UTC

Description Lukas Slebodnik 2017-05-04 13:03:12 UTC 
+++ This bug was initially created as a clone of Bug #1447411 +++

SELinux is preventing systemd from create access 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                          vm-058-043.example.com
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-251.fc26.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     vm-058-043.example.com
Platform                      Linux vm-058-043.example.com
                              4.11.0-0.rc8.git0.1.fc26.x86_64 #1 SMP Mon Apr 24
                              15:42:54 UTC 2017 x86_64 x86_64
Alert Count                   1
First Seen                    2017-05-02 18:00:30 CEST
Last Seen                     2017-05-02 18:00:30 CEST
Local ID                      5ac9a2c2-e4fb-4ad1-97e6-e46f3aab16cd

Raw Audit Messages
type=AVC msg=audit(1493740830.125:704): 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


Hash: systemd,init_t,unconfined_service_t,unix_stream_socket,create

--- Additional comment from Lukas Slebodnik on 2017-05-02 12:22:17 EDT ---

How to reproduce:
dnf install --nogpgcheck --enablerepo=rawhide sssd-kcm // will backport to f26 in few weeks :-) 
systemctl enable sssd-secrets.socket sssd-kcm.socket
systemctl start sssd-kcm.socket

AVCs in permissive mode

type=AVC msg=audit(05/02/2017 18:01:25.561:727) : 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(05/02/2017 18:01:25.561:728) : 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(05/02/2017 18:01:25.562:729) : 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(05/02/2017 18:01:25.563:730) : avc:  denied  { listen } for  pid=1 comm=systemd path=/run/.heim_org.h5l.kcm-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 2017-05-02 12:25:58 EDT ---

There is also an AVC when using sssd-kcm.
sssd-kcm store KRB5 tickets in sssd-secrets and there is deny to write there.

Enforcing:
type=AVC msg=audit(05/02/2017 18:13:11.178:894) : avc:  denied  { write } for  pid=3252 comm=sssd_kcm name=secrets.socket dev="tmpfs" ino=49715 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:sssd_var_run_t:s0 tclass=sock_file permissive=0 

Permissive:
type=AVC msg=audit(05/02/2017 18:15:50.917:932) : avc:  denied  { write } for  pid=3317 comm=sssd_kcm name=secrets.socket dev="tmpfs" ino=49769 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:sssd_var_run_t:s0 tclass=sock_file permissive=1

SELinux is preventing sssd_kcm from write access on the sock_file secrets.socket.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that sssd_kcm should be allowed write access on the secrets.socket sock_file 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 'sssd_kcm' --raw | audit2allow -M my-sssdkcm
# semodule -X 300 -i my-sssdkcm.pp


Additional Information:
Source Context                system_u:system_r:sssd_t:s0
Target Context                system_u:object_r:sssd_var_run_t:s0
Target Objects                secrets.socket [ sock_file ]
Source                        sssd_kcm
Source Path                   sssd_kcm
Port                          <Unknown>
Host                          vm-058-043.example.com
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-251.fc26.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     vm-058-043.example.com
Platform                      Linux vm-058-043.example.com
                              4.11.0-0.rc8.git0.1.fc26.x86_64 #1 SMP Mon Apr 24
                              15:42:54 UTC 2017 x86_64 x86_64
Alert Count                   7
First Seen                    2017-05-02 18:06:19 CEST
Last Seen                     2017-05-02 18:13:11 CEST
Local ID                      a2fe4f0e-d1af-4482-8559-6264a8190e6d

Raw Audit Messages
type=AVC msg=audit(1493741591.178:894): avc:  denied  { write } for  pid=3252 comm="sssd_kcm" name="secrets.socket" dev="tmpfs" ino=49715 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:sssd_var_run_t:s0 tclass=sock_file permissive=0


Hash: sssd_kcm,sssd_t,sssd_var_run_t,sock_file,write

--- Additional comment from Lukas Slebodnik on 2017-05-04 08:58:34 EDT ---

PR: https://github.com/fedora-selinux/selinux-policy-contrib/pull/11
Comment 8 Lukas Slebodnik 2017-05-16 08:01:26 UTC 
> type=SYSCALL msg=audit(05/16/2017 09:27:53.787:237) : arch=x86_64
> syscall=bind success=no exit=EACCES(Permission denied) a0=0xb
> a1=0x7ffe9cfe3920 a2=0x6e a3=0x7ffe9cfe36d0 items=2 ppid=1 pid=18583
> auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root
> sgid=root fsgid=root tty=(none) ses=unset comm=sssd_kcm
> exe=/usr/libexec/sssd/sssd_kcm subj=system_u:system_r:sssd_t:s0 key=(null) 
>type=AVC msg=audit(05/16/2017 09:29:59.596:249) : avc:  denied  { create } for  >pid=18689 comm=sssd_kcm name=.heim_org.h5l.kcm-socket >scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:var_run_t:s0 >tclass=sock_file permissive=1 

I've just realized that tcontext is wrong system_u:object_r:var_run_t:s0 vs system_u:object_r:sssd_var_run_t:s0
Comment 9 Lukas Slebodnik 2017-05-16 08:59:06 UTC 
And I am not quite sure why the socket is created with wrong SELinux context

sh# systemctl stop sssd-kcm.{socket,service}
sh# rm -f /var/run/.heim_org.h5l.kcm-socket

sh# matchpathcon /var/run/.heim_org.h5l.kcm-socket /run/.heim_org.h5l.kcm-socket
/var/run/.heim_org.h5l.kcm-socket       system_u:object_r:sssd_var_run_t:s0
/run/.heim_org.h5l.kcm-socket   system_u:object_r:sssd_var_run_t:s0

sh# systemctl start sssd-kcm.service
sh# ls -Z /var/run/.heim_org.h5l.kcm-socket
system_u:object_r:var_run_t:s0 /var/run/.heim_org.h5l.kcm-socket
Comment 10 Lukas Vrabec 2017-05-16 09:06:50 UTC 
There is bug in the sssd SELinux module. 

We forgot add file transition to allow sssd_t domain create sock_files in /var/run/ directory. 

You can verify it using "sesearch" command: 
# sesearch -T -s sssd_t -t var_run_t
Found 2 semantic te rules:
   type_transition sssd_t var_run_t : file sssd_var_run_t; 
   type_transition sssd_t var_run_t : dir sssd_var_run_t; 

There should be also one more rule: 
type_transition sssd_t var_run_t : sock_file sssd_var_run_t; 

Lukas, 
Do you want create PR to practice writing SELinux rules? :) 

Thanks,
Lukas.
Comment 11 Lukas Slebodnik 2017-05-16 11:08:54 UTC 
(In reply to Lukas Vrabec from comment #10)
> There is bug in the sssd SELinux module. 
> 
> We forgot add file transition to allow sssd_t domain create sock_files in
> /var/run/ directory. 
> 
> You can verify it using "sesearch" command: 
> # sesearch -T -s sssd_t -t var_run_t
> Found 2 semantic te rules:
>    type_transition sssd_t var_run_t : file sssd_var_run_t; 
>    type_transition sssd_t var_run_t : dir sssd_var_run_t; 
> 
> There should be also one more rule: 
> type_transition sssd_t var_run_t : sock_file sssd_var_run_t; 
> 
> Lukas, 
> Do you want create PR to practice writing SELinux rules? :) 
>
It should be following oneliner :-)
-files_pid_filetrans(sssd_t, sssd_var_run_t, { file dir })
+files_pid_filetrans(sssd_t, sssd_var_run_t, { file dir sock_file })

It does not worth a PR
Comment 19 Lukas Slebodnik 2017-05-18 19:21:27 UTC 
I can see the same issue as in fedora

[root@vm-081 ~]# systemctl stop sssd-kcm.{socket,service}
[root@vm-081 ~]# rm -f /var/run/.heim_org.h5l.kcm-socket
[root@vm-081 ~]# systemctl start sssd-kcm.socket
 
[root@vm-081 ~]# ls -lZ /var/run/.heim_org.h5l.kcm-socket 
srw-rw-rw-. root root system_u:object_r:var_run_t:s0   /var/run/.heim_org.h5l.kcm-socket

[root@vm-081 ~]# semanage fcontext -l | grep heim_org
/var/run/\.heim_org\.h5l\.kcm-socket               socket             system_u:object_r:sssd_var_run_t:s0 

[root@vm-081 ~]# matchpathcon /var/run/.heim_org.h5l.kcm-socket
/var/run/.heim_org.h5l.kcm-socket       system_u:object_r:sssd_var_run_t:s0

[root@vm-081 ~]# rpm -q selinux-policy
selinux-policy-3.13.1-151.el7.noarch

Right SELinux context is used with starting service directly instead of socket.
Is there some missing transition rule?
Comment 21 errata-xmlrpc 2017-08-01 15:26:23 UTC 
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/RHBA-2017:1861
Note You need to log in before you can comment on or make changes to this bug.