Description of problem: During CKI tests we hit the following avc denials: type=AVC msg=audit(1636694856.946:1176): avc: denied { setgid } for pid=1084066 comm="sss_cache" capability=6 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:groupadd_t:s0 tclass=capability permissive=1 type=AVC msg=audit(1636678713.009:16916): avc: denied { setgid } for pid=494719 comm="sss_cache" capability=6 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:groupadd_t:s0 tclass=capability permissive=0 Version-Release number of selected component (if applicable): selinux-policy-35.5-1.fc36.noarch How reproducible: easily Steps to Reproduce: 1. Run cki test like xfstests - ext4 [1] Additional info: SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 selinux-policy-35.5-1.fc36.noarch test logs: https://datawarehouse.cki-project.org/kcidb/tests/1848595 [1] https://gitlab.com/cki-project/kernel-tests/-/tree/main/filesystems/xfs/xfstests
Sumit, Can you tell me at which situations sss_cache is called? I understand it is: - command line - useradd/groupadd Are there any services calling the command directly? Additionally, what exactly it does, removes the cache files, talks to a service, etc.? sss_cache is labeled with the generic bin_t type which means it is executed in the context of the calling process. The question for SELinux is now: Can we label it with sssd_exec_t as sssd is, and subsequently allow transitions from SELinux domains like useradd_t? # ls -Z /usr/sbin/sss* system_u:object_r:bin_t:s0 /usr/sbin/sss_cache system_u:object_r:sssd_exec_t:s0 /usr/sbin/sssd
*** Bug 2023477 has been marked as a duplicate of this bug. ***
(In reply to Zdenek Pytela from comment #1) > Sumit, > > Can you tell me at which situations sss_cache is called? I understand it is: > - command line > - useradd/groupadd > > Are there any services calling the command directly? Additionally, what > exactly it does, removes the cache files, talks to a service, etc.? Hi, I'm not aware of any other callers. sss_cache does not remove files but reads files from /var/lib/sss/db/ and writes to some of them. All those files should have the label system_u:object_r:sssd_var_lib_t:s0. Additionally it will send a signal to the 'sssd' process running with label system_u:system_r:sssd_t:s0. I'm a bit puzzled about the 'setgid' in the denial message because afaik sss_cache does not call setgid(). Even when running sss_cache with strace I see no call to setgid(). bye, Sumit > > sss_cache is labeled with the generic bin_t type which means it is executed > in the context of the calling process. The question for SELinux is now: Can > we label it with sssd_exec_t as sssd is, and subsequently allow transitions > from SELinux domains like useradd_t? > > # ls -Z /usr/sbin/sss* > system_u:object_r:bin_t:s0 /usr/sbin/sss_cache > system_u:object_r:sssd_exec_t:s0 /usr/sbin/sssd
Thank you. FYI the full audit record is: ---- type=PROCTITLE msg=audit(11/09/2021 09:51:41.159:618) : proctitle=sss_cache -G type=SYSCALL msg=audit(11/09/2021 09:51:41.159:618) : arch=x86_64 syscall=setresgid success=yes exit=0 a0=unset a1=root a2=unset a3=0x0 items=0 ppid=1649 pid=1654 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=3 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(11/09/2021 09:51:41.159:618) : avc: denied { setgid } for pid=1654 comm=sss_cache capability=setgid 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 so the syscall actually is setresgid() which I can find in src/util/become_user.c.
*** Bug 2020558 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Install nVidia Linux Graphics Driver from Gnome-Software hashmarkername: setroubleshoot kernel: 5.14.18-300.fc35.x86_64 package: selinux-policy-targeted-35.5-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
Similar problem has been detected: I got this warning message when I first started using my Fedora 35 KDE installation, after installing SELinux Alert Browser. Searching the Web suggests that it is a misconfiguration in SELinux, and that it is interfering with some process related to maintaining my SSD. This is the solution in the SELinux Alert Browser: You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 'sss_cache' --raw | audit2allow -M my-ssscache # semodule -X 300 -i my-ssscache.pp hashmarkername: setroubleshoot kernel: 5.14.18-300.fc35.x86_64 package: selinux-policy-targeted-35.5-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
Similar problem has been detected: Occurred during auto-installation of autossh: [sjhudson@serenity ~]$ autossh treehouse bash: autossh: command not found... Install package 'autossh' to provide command 'autossh'? [N/y] y * Waiting in queue... The following packages have to be installed: autossh-1.4g-7.fc35.x86_64 Utility to autorestart SSH tunnels Proceed with changes? [N/y] y * Waiting in queue... * Waiting for authentication... * Waiting in queue... * Downloading packages... * Requesting data... * Testing changes... * Installing packages... usage: autossh [-V] [-M monitor_port[:echo_port]] [-f] [SSH_OPTIONS] -M specifies monitor port. May be overridden by environment variable AUTOSSH_PORT. 0 turns monitoring loop off. Alternatively, a port for an echo service on the remote machine may be specified. (Normally port 7.) -f run in background (autossh handles this, and does not pass it to ssh.) -V print autossh version and exit. Environment variables are: AUTOSSH_GATETIME - how long must an ssh session be established before we decide it really was established (in seconds). Default is 30 seconds; use of -f flag sets this to 0. AUTOSSH_LOGFILE - file to log to (default is to use the syslog facility) AUTOSSH_LOGLEVEL - level of log verbosity AUTOSSH_MAXLIFETIME - set the maximum time to live (seconds) AUTOSSH_MAXSTART - max times to restart (default is no limit) AUTOSSH_MESSAGE - message to append to echo string (max 64 bytes) AUTOSSH_PATH - path to ssh if not default AUTOSSH_PIDFILE - write pid to this file AUTOSSH_POLL - how often to check the connection (seconds) AUTOSSH_FIRST_POLL - time before first connection check (seconds) AUTOSSH_PORT - port to use for monitor connection AUTOSSH_DEBUG - turn logging to maximum verbosity and log to stderr hashmarkername: setroubleshoot kernel: 5.14.17-301.fc35.x86_64 package: selinux-policy-targeted-35.5-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
I see this in Fedora 35 as well, changing the affected version to 35.
Similar problem has been detected: Error appeared during installation of the deluge-2.0.3-18.fc35.noarch.rpm package along with the following dependencies GeoIP 1.6.12-10.fc35 GeoIP-GeoLite-data 2018.06-8.fc35 SDL2_image 2.0.5-7.fc35 SDL2_mixer 2.0.4-9.fc35 SDL2_ttf 2.0.15-8.fc35 boost-python3 1.76.0-4.fc35 deluge-common 2.0.3-18.fc35 deluge-console 2.0.3-18.fc35 deluge-daemon 2.0.3-18.fc35 deluge-gtk 2.0.3-18.fc35 deluge-images 2.0.3-18.fc35 deluge-web 2.0.3-18.fc35 flexiblas 3.0.4-6.fc35 flexiblas-netlib 3.0.4-6.fc35 flexiblas-openblas-openmp 3.0.4-6.fc35 gnu-free-fonts-common 20120503-25.fc35 gnu-free-sans-fonts 20120503-25.fc35 libgfortran 11.2.1-1.fc35 libquadmath 11.2.1-1.fc35 libtomcrypt 1.18.2-13.fc35 libtommath 1.2.0-5.fc35 openblas 0.3.18-1.fc35 openblas-openmp 0.3.18-1.fc35 portmidi 217-41.fc35 python3-Automat 20.2.0-8.fc35 python3-attrs 21.2.0-4.fc35 python3-constantly 15.1.0-14.fc35 python3-cryptography 3.4.7-5.fc35 python3-hyperlink 21.0.0-4.fc35 python3-incremental 21.3.0-1.fc35 python3-mako 1.1.4-6.fc35 python3-paste 3.5.0-5.fc35 python3-pyOpenSSL 21.0.0-1.fc35 python3-pyasn1 0.4.8-7.fc35 python3-pyasn1-modules 0.4.8-7.fc35 python3-rencode 1.0.6-15.fc35 python3-service-identity 21.1.0-3.fc35 python3-tempita 0.5.2-2.fc35 python3-twisted 21.7.0-2.fc35 python3-twisted+tls 21.7.0-2.fc35 python3-typing-extensions 3.7.4.3-4.fc35 python3-zope-event 4.2.0-22.fc35 python3-zope-interface 5.4.0-3.fc35 rb_libtorrent 2.0.4-5.fc35 rb_libtorrent-python3 2.0.4-5.fc35 python3-GeoIP 1.3.2-21.fc35 python3-beaker 1.10.0-12.fc35 python3-crypto 2.6.1-36.fc35 python3-numpy 1:1.21.1-1.fc35 python3-pygame 2.1.0-1.fc35 hashmarkername: setroubleshoot kernel: 5.15.5-200.fc35.x86_64 package: selinux-policy-targeted-35.5-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
OpenQA FreeIPA tests also see this in Rawhide for few composes already: https://openqa.fedoraproject.org/tests/1078183
Similar problem has been detected: This popped up right after I had installed the nvidia-390 driver. I didn't do anything else. hashmarkername: setroubleshoot kernel: 5.15.6-200.fc35.x86_64 package: selinux-policy-targeted-35.6-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
Similar problem has been detected: It seems random hashmarkername: setroubleshoot kernel: 5.15.6-200.fc35.x86_64 package: selinux-policy-targeted-35.6-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
Similar problem has been detected: The error occurs after PHP modules installation dnf install php-common php-fpm php-ast php-bcmath php-ffi php-gd php-gmp \ php-intl php-json php-ldap php-memcached php-mbstring php-mysqlnd \ php-opcache php-pdo php-pgsql php-process php-sodium php-xml \ php-pecl-apcu php-pecl-igbinary php-pecl-msgpack php-pecl-redis5 php-pecl-zip hashmarkername: setroubleshoot kernel: 5.15.6-200.fc35.x86_64 package: selinux-policy-targeted-35.6-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
One of many reproducers: # yum -y install cyrus-sasl ---- type=PROCTITLE msg=audit(12/14/2021 04:30:19.723:498) : proctitle=sss_cache -G type=SYSCALL msg=audit(12/14/2021 04:30:19.723:498) : arch=x86_64 syscall=setresgid success=yes exit=0 a0=unset a1=root a2=unset a3=0x0 items=0 ppid=1317 pid=1322 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=4 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(12/14/2021 04:30:19.723:498) : avc: denied { setgid } for pid=1322 comm=sss_cache capability=setgid 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 ---- type=PROCTITLE msg=audit(12/14/2021 04:30:19.822:502) : proctitle=sss_cache -UG type=SYSCALL msg=audit(12/14/2021 04:30:19.822:502) : arch=x86_64 syscall=setresgid success=yes exit=0 a0=unset a1=root a2=unset a3=0x7f9b52d8aac0 items=0 ppid=1324 pid=1327 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=4 comm=sss_cache exe=/usr/sbin/sss_cache subj=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(12/14/2021 04:30:19.822:502) : avc: denied { setgid } for pid=1327 comm=sss_cache capability=setgid scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tclass=capability permissive=0 ---- Basically, any package that brings a new user or a new group can trigger such SELinux denials. # repoquery --whatrequires /usr/sbin/useradd ... # repoquery --whatrequires /usr/sbin/groupadd ... There are other programs which have the same SELinux label: # ls -Z /usr/sbin/user* system_u:object_r:useradd_exec_t:s0 /usr/sbin/useradd system_u:object_r:useradd_exec_t:s0 /usr/sbin/userdel system_u:object_r:useradd_exec_t:s0 /usr/sbin/usermod # ls -Z /usr/sbin/group* system_u:object_r:groupadd_exec_t:s0 /usr/sbin/groupadd system_u:object_r:groupadd_exec_t:s0 /usr/sbin/groupdel system_u:object_r:bin_t:s0 /usr/sbin/groupmems system_u:object_r:groupadd_exec_t:s0 /usr/sbin/groupmod # I guess that all these programs call the sss_cache program intentionally: # strings `which useradd` | grep sss_cache /usr/sbin/sss_cache %s: sss_cache did not terminate normally (signal %d) %s: sss_cache exited with status %d # strings `which groupadd` | grep sss_cache %s: sss_cache did not terminate normally (signal %d) %s: sss_cache exited with status %d /usr/sbin/sss_cache #
Similar problem has been detected: While installing Docker, it ask me for gpg key fingerprint is true or not and I pressed yes, then this happened and I tried install firecracker before installing docker(which affects docker(i dont know firecracker needs docker)). Firecracker repository can be found in here: https://github.com/firecracker-microvm/firecracker Following gpg key is here: Importing GPG key 0x621E9F35: Userid : "Docker Release (CE rpm) <docker>" Fingerprint: 060A 61C5 1B55 8A7F 742B 77AA C52F EB6B 621E 9F35 From : https://download.docker.com/linux/fedora/gpg Is this ok [y/N]: y hashmarkername: setroubleshoot kernel: 5.15.7-200.fc35.x86_64 package: selinux-policy-targeted-35.6-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
I've submitted a Fedora draft PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/979
Similar problem has been detected: Yum install of libvirt with sssd running seems to be the cause hashmarkername: setroubleshoot kernel: 5.15.6-200.fc35.x86_64 package: selinux-policy-targeted-35.7-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
Similar problem has been detected: I'm trying to update Anydesk app hashmarkername: setroubleshoot kernel: 5.15.12-200.fc35.x86_64 package: selinux-policy-targeted-35.7-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
Similar problem has been detected: When installing gns: sudo dnf install gns3-server gns3-gui hashmarkername: setroubleshoot kernel: 5.15.12-200.fc35.x86_64 package: selinux-policy-targeted-35.7-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
Similar problem has been detected: I deleted a user using gnome settings hashmarkername: setroubleshoot kernel: 5.15.14-200.fc35.x86_64 package: selinux-policy-targeted-35.8-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
Similar problem has been detected: dnf run from the command line to do updates. hashmarkername: setroubleshoot kernel: 5.15.14-200.fc35.x86_64 package: selinux-policy-targeted-35.9-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
Similar problem has been detected: Updates run using dnf on the command line. hashmarkername: setroubleshoot kernel: 5.15.14-200.fc35.x86_64 package: selinux-policy-targeted-35.9-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
Similar problem has been detected: Ran dnf from the command line to do updates. hashmarkername: setroubleshoot kernel: 5.15.14-200.fc35.x86_64 reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
*** Bug 2041864 has been marked as a duplicate of this bug. ***
PR: https://github.com/fedora-selinux/selinux-policy/pull/1023
Similar problem has been detected: uruchomienie środowiska graficznego KDE hashmarkername: setroubleshoot kernel: 5.15.16-200.fc35.x86_64 package: selinux-policy-targeted-35.11-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
After upgrading the selinux-policy* packages to version 35.12-1.fc36, the following SELinux denials started to appear: ---- type=PROCTITLE msg=audit(01/28/2022 09:34:53.572:606) : proctitle=/usr/sbin/groupadd -g 25 -f -r named type=PATH msg=audit(01/28/2022 09:34:53.572:606) : item=0 name=/usr/sbin/sss_cache inode=13299 dev=fc:01 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:sssd_exec_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(01/28/2022 09:34:53.572:606) : cwd=/ type=SYSCALL msg=audit(01/28/2022 09:34:53.572:606) : arch=x86_64 syscall=execve success=no exit=EACCES(Permission denied) a0=0x556ef589fd9d a1=0x7fffbd463510 a2=0x7fffbd463508 a3=0x7f7f970ce088 items=1 ppid=1849 pid=1854 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=3 comm=groupadd exe=/usr/sbin/groupadd subj=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 key=(null) type=SELINUX_ERR msg=audit(01/28/2022 09:34:53.572:606) : op=security_compute_sid invalid_context=unconfined_u:unconfined_r:sssd_t:s0-s0:c0.c1023 scontext=unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sssd_exec_t:s0 tclass=process ---- type=PROCTITLE msg=audit(01/28/2022 09:34:53.689:610) : proctitle=/usr/sbin/useradd -u 25 -r -N -M -g named -s /sbin/nologin -d /var/named -c Named named type=PATH msg=audit(01/28/2022 09:34:53.689:610) : item=0 name=/usr/sbin/sss_cache inode=13299 dev=fc:01 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:sssd_exec_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(01/28/2022 09:34:53.689:610) : cwd=/ type=SYSCALL msg=audit(01/28/2022 09:34:53.689:610) : arch=x86_64 syscall=execve success=no exit=EACCES(Permission denied) a0=0x5614d7b727a1 a1=0x7ffd4aa59b20 a2=0x7ffd4aa59b18 a3=0x7f2c9c553088 items=1 ppid=1856 pid=1859 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=3 comm=useradd exe=/usr/sbin/useradd subj=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 key=(null) type=SELINUX_ERR msg=audit(01/28/2022 09:34:53.689:610) : op=security_compute_sid invalid_context=unconfined_u:unconfined_r:sssd_t:s0-s0:c0.c1023 scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sssd_exec_t:s0 tclass=process ---- Steps to Reproduce: # yum -y install bind It looks like the processes running under unconfined_r do not have access to sssd_t or sssd_exec_t types.
Similar problem has been detected: it's showed when i install opentracker-common, opentracker-ipv4, and opentracker-ipv6 using dnf. hashmarkername: setroubleshoot kernel: 5.15.17-200.fc35.x86_64 package: selinux-policy-targeted-35.11-1.fc35.noarch reason: SELinux is preventing sss_cache from using the 'setgid' capabilities. type: libreport
FEDORA-2022-20f36a8b0e has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-20f36a8b0e
FEDORA-2022-20f36a8b0e has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-20f36a8b0e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-20f36a8b0e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-20f36a8b0e has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.