Bug 1884179

Summary: SELinux prevents sss_cache from calling the utime syscall
Product: Red Hat Enterprise Linux 8 Reporter: Milos Malik <mmalik>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.3CC: lvrabec, mmalik, plautrba, sbose, sgoveas, ssekidde
Target Milestone: rcKeywords: Triaged
Target Release: 8.4   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-18 14:58:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Milos Malik 2020-10-01 09:39:10 UTC
Description of problem:
 * hundreds of SELinux denials appear when packages like mailman are being installed
 * it seems that sss_cache program is called by groupadd, because the process runs under groupadd_t 

Version-Release number of selected component (if applicable):
selinux-policy-3.14.3-54.el8.noarch
selinux-policy-devel-3.14.3-54.el8.noarch
selinux-policy-doc-3.14.3-54.el8.noarch
selinux-policy-minimum-3.14.3-54.el8.noarch
selinux-policy-mls-3.14.3-54.el8.noarch
selinux-policy-sandbox-3.14.3-54.el8.noarch
selinux-policy-targeted-3.14.3-54.el8.noarch
sssd-2.3.0-9.el8.x86_64
sssd-ad-2.3.0-9.el8.x86_64
sssd-client-2.3.0-9.el8.x86_64
sssd-common-2.3.0-9.el8.x86_64
sssd-common-pac-2.3.0-9.el8.x86_64
sssd-dbus-2.3.0-9.el8.x86_64
sssd-ipa-2.3.0-9.el8.x86_64
sssd-kcm-2.3.0-9.el8.x86_64
sssd-krb5-2.3.0-9.el8.x86_64
sssd-krb5-common-2.3.0-9.el8.x86_64
sssd-ldap-2.3.0-9.el8.x86_64
sssd-libwbclient-2.3.0-9.el8.x86_64
sssd-nfs-idmap-2.3.0-9.el8.x86_64
sssd-polkit-rules-2.3.0-9.el8.x86_64
sssd-proxy-2.3.0-9.el8.x86_64
sssd-tools-2.3.0-9.el8.x86_64
sssd-winbind-idmap-2.3.0-9.el8.x86_64

How reproducible:
 * not sure yet, but it happens when a package which creates a user or a group is being installed and SSSD is running

Steps to Reproduce:
1. get a RHEL-8.3 machine (targeted policy is active)
2. make sure the SSSD is running
3. install or reinstall the mailman package
4. search for SELinux denials

Actual results:
----
type=PROCTITLE msg=audit(10/01/2020 11:09:10.235:1518) : proctitle=sss_cache -G 
type=PATH msg=audit(10/01/2020 11:09:10.235:1518) : item=0 name=/var/lib/sss/db/timestamps_implicit_files.ldb inode=209267 dev=08:02 mode=file,600 ouid=sssd ogid=sssd rdev=00:00 obj=system_u:object_r:sssd_var_lib_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(10/01/2020 11:09:10.235:1518) : cwd=/ 
type=SYSCALL msg=audit(10/01/2020 11:09:10.235:1518) : arch=x86_64 syscall=utime success=yes exit=0 a0=0x5618a824a550 a1=0x0 a2=0x189000 a3=0x5618a8389460 items=1 ppid=22919 pid=22975 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=tty1 ses=1 comm=sss_cache exe=/usr/sbin/sss_cache subj=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(10/01/2020 11:09:10.235:1518) : avc:  denied  { fowner } for  pid=22975 comm=sss_cache capability=fowner  scontext=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 tclass=capability permissive=0 
----

Expected results:
 * no such denials

Comment 2 Milos Malik 2020-10-01 09:43:22 UTC
# ls -Z `which sss_cache`
system_u:object_r:bin_t:s0 /usr/sbin/sss_cache
# ps -efZ | grep sss
system_u:system_r:sssd_t:s0     root        1109       1  0 10:12 ?        00:00:00 /usr/sbin/sssd -i --logger=files
system_u:system_r:sssd_t:s0     sssd        1390    1109  0 10:12 ?        00:00:03 /usr/libexec/sssd/sssd_nss --uid 963 --gid 958 --logger=files
system_u:system_r:sssd_t:s0     sssd        1391    1109  0 10:12 ?        00:00:00 /usr/libexec/sssd/sssd_pam --uid 963 --gid 958 --logger=files
system_u:system_r:sssd_t:s0     root        1397    1109  0 10:12 ?        00:00:00 /usr/libexec/sssd/sssd_ifp --uid 0 --gid 0 --logger=files
system_u:system_r:sssd_t:s0     sssd       22968    1109  0 11:08 ?        00:00:00 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 963 --gid 958 --logger=files
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 34909 26671  0 11:39 pts/0 00:00:00 grep --color=auto sss
# cat /etc/sssd/sssd.conf 
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, ifp
domains =
user = sssd

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[ifp]
allowed_uids = root
user_attributes = +mail, +givenname, +sn
# ls -iZ /var/lib/sss/db/
 163059 system_u:object_r:sssd_var_lib_t:s0 cache_implicit_files.ldb
1117209 system_u:object_r:sssd_var_lib_t:s0 cache_ldap.ldb
 209166 system_u:object_r:sssd_var_lib_t:s0 config.ldb
 163256 system_u:object_r:sssd_var_lib_t:s0 sssd.ldb
 209267 system_u:object_r:sssd_var_lib_t:s0 timestamps_implicit_files.ldb
1117210 system_u:object_r:sssd_var_lib_t:s0 timestamps_ldap.ldb
# ls -il /var/lib/sss/db/
total 9908
 163059 -rw-------. 1 sssd sssd 3391488 Oct  1 11:31 cache_implicit_files.ldb
1117209 -rw-------. 1 root root 1286144 May 25 10:58 cache_ldap.ldb
 209166 -rw-------. 1 sssd sssd 1286144 Oct  1 10:12 config.ldb
 163256 -rw-------. 1 root root 1286144 Jul 27  2018 sssd.ldb
 209267 -rw-------. 1 sssd sssd 1609728 Oct  1 11:31 timestamps_implicit_files.ldb
1117210 -rw-------. 1 root root 1286144 Jan  9  2020 timestamps_ldap.ldb
#

Comment 8 Sumit Bose 2020-11-09 10:27:52 UTC
Hi,

I can reproduce the issue. The reason is that SSSD is configured to run as user `sssd` (`user = sssd` in sssd.conf) and as a result the ownership of the case file is:

     163059 -rw-------. 1 sssd sssd 3391488 Oct  1 11:31 cache_implicit_files.ldb

so that only the `sssd` user can access it. When calling `sss_cache` in a confined environment, e.g. running as sub-task of yum and rpm, with restricted capabilities even when running as root with uid=0 some operations might be rejected.

In the given case it is `sys_utime` and it looks the `utime` glibc even hides the error form the user since when running with strace I cannot see an error returned by utime. Nevertheless since it looks that all other operations related to flushing the cache are working as expected I think a rule can be added to allow the `sys_utime` call and is granting the `fowner` capability is the only way I'm fine with it from the SSSD perspective.

bye,
Sumit

Comment 9 Milos Malik 2020-11-09 10:34:15 UTC
Thank you for looking into it. We appreciate the results of your analysis.

Comment 20 errata-xmlrpc 2021-05-18 14:58:17 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 (selinux-policy bug fix and enhancement update), 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-2021:1639