Bug 1884179
Summary: | SELinux prevents sss_cache from calling the utime syscall | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Milos Malik <mmalik> |
Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.3 | CC: | lvrabec, mmalik, plautrba, sbose, sgoveas, ssekidde |
Target Milestone: | rc | Keywords: | 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
# 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 # 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 Thank you for looking into it. We appreciate the results of your analysis. 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 |