SELinux is preventing /usr/sbin/groupadd from read access on the fifo_file fifo_file. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that groupadd should be allowed read access on the fifo_file fifo_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 'groupadd' --raw | audit2allow -M my-groupadd # semodule -X 300 -i my-groupadd.pp Additional Information: Source Context system_u:system_r:groupadd_t:s0 Target Context system_u:system_r:unconfined_service_t:s0 Target Objects fifo_file [ fifo_file ] Source groupadd Source Path /usr/sbin/groupadd Port <Unknown> Host host.example.com Source RPM Packages shadow-utils-4.6-16.fc31.x86_64 Target RPM Packages Policy RPM selinux-policy-3.14.4-35.fc31.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name host.example.com Platform Linux host.example.com 5.3.0-1.fc31.x86_64 #1 SMP Mon Sep 16 12:34:42 UTC 2019 x86_64 x86_64 Alert Count 1 First Seen 2019-09-21 18:53:57 CEST Last Seen 2019-09-21 18:53:57 CEST Local ID b31e4f50-43ea-4dde-b9cc-38bc3ff00ae8 Raw Audit Messages type=AVC msg=audit(1569084837.395:157): avc: denied { read } for pid=16013 comm="groupadd" path="pipe:[55116]" dev="pipefs" ino=55116 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=fifo_file permissive=1 type=SYSCALL msg=audit(1569084837.395:157): arch=x86_64 syscall=execve success=yes exit=0 a0=557d40504650 a1=557d40504440 a2=557d405046b0 a3=8 items=2 ppid=16011 pid=16013 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=groupadd exe=/usr/sbin/groupadd subj=system_u:system_r:groupadd_t:s0 key=(null) type=CWD msg=audit(1569084837.395:157): cwd=/ type=PATH msg=audit(1569084837.395:157): item=0 name=/sbin/groupadd inode=25168485 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:groupadd_exec_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(1569084837.395:157): item=1 name=/lib64/ld-linux-x86-64.so.2 inode=25167333 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 Hash: groupadd,groupadd_t,unconfined_service_t,fifo_file,read
SELinux is preventing /usr/sbin/groupadd from ioctl access on the fifo_file fifo_file. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that groupadd should be allowed ioctl access on the fifo_file fifo_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 'groupadd' --raw | audit2allow -M my-groupadd # semodule -X 300 -i my-groupadd.pp Additional Information: Source Context system_u:system_r:groupadd_t:s0 Target Context system_u:system_r:unconfined_service_t:s0 Target Objects fifo_file [ fifo_file ] Source groupadd Source Path /usr/sbin/groupadd Port <Unknown> Host host.example.com Source RPM Packages shadow-utils-4.6-16.fc31.x86_64 Target RPM Packages Policy RPM selinux-policy-3.14.4-35.fc31.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name host.example.com Platform Linux host.example.com 5.3.0-1.fc31.x86_64 #1 SMP Mon Sep 16 12:34:42 UTC 2019 x86_64 x86_64 Alert Count 1 First Seen 2019-09-21 18:53:57 CEST Last Seen 2019-09-21 18:53:57 CEST Local ID 683f84c3-d7da-471f-aa74-9dfcbf05baf9 Raw Audit Messages type=AVC msg=audit(1569084837.430:159): avc: denied { ioctl } for pid=16013 comm="groupadd" path="pipe:[55116]" dev="pipefs" ino=55116 ioctlcmd=0x5401 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=fifo_file permissive=1 type=SYSCALL msg=audit(1569084837.430:159): arch=x86_64 syscall=ioctl success=no exit=ENOTTY a0=0 a1=5401 a2=7ffd47c5e9b0 a3=7ffd47c5dc70 items=0 ppid=16011 pid=16013 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=groupadd exe=/usr/sbin/groupadd subj=system_u:system_r:groupadd_t:s0 key=(null) Hash: groupadd,groupadd_t,unconfined_service_t,fifo_file,ioctl
Moving to shadow-utils for evaluation.
BTW it happened as part of dnf transaction. I assumesome scriptlet called groupadd
---- time->Wed Sep 18 21:29:26 2019 type=AVC msg=audit(1568834966.119:109): avc: denied { read } for pid=1227 comm="groupadd" path="pipe:[28975]" dev="pipefs" ino=28975 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=fifo_file permissive=0 ---- time->Wed Sep 18 21:29:27 2019 type=AVC msg=audit(1568834967.482:113): avc: denied { read } for pid=1254 comm="groupadd" path="pipe:[29524]" dev="pipefs" ino=29524 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=fifo_file permissive=0
I suppose this could be legitimate if sssd is enabled. Although the unconfined_service_t label is strange. Anyway I would need more information - what modules are in nsswitch.conf, eventually also the strace output.
sssd has different context than system_u:system_r:unconfined_service_t * sss_cache was removed on the system (but AVC happen even with sss_cache installed) * sssd was enabled. * nsswitch.conf is default one from f31.
(In reply to Lukas Slebodnik from comment #6) > sssd has different context than system_u:system_r:unconfined_service_t Is there anything else running with this context? > * sss_cache was removed on the system (but AVC happen even with sss_cache > installed) > * sssd was enabled. > * nsswitch.conf is default one from f31. Could you please attach/paste it here?
The reproducer is quite complicated. I am able to reproduce it just from beakerlib test. (maybe some restraintd magic issue) I am not able to reproduce with installing the package manually. Here is more context Sep 23 23:36:16 host.example.com audit[14803]: AVC avc: denied { read } for pid=14803 comm="groupadd" path="pipe:[49926]" dev="pipefs" ino=49926 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=fifo_file permissive=0 Sep 23 23:36:16 host.example.com audit[14803]: ADD_GROUP pid=14803 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:groupadd_t:s0 msg='op=add-group id=991 exe="/usr/sbin/groupadd" hostname=? addr=? terminal=? res=success' Sep 23 23:36:16 host.example.com groupadd[14803]: group added to /etc/group: name=printadmin, GID=991 Sep 23 23:36:16 host.example.com audit[14803]: GRP_MGMT pid=14803 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:groupadd_t:s0 msg='op=add-shadow-group id=991 exe="/usr/sbin/groupadd" hostname=? addr=? terminal=? res=success' Sep 23 23:36:16 host.example.com groupadd[14803]: group added to /etc/gshadow: name=printadmin Sep 23 23:36:16 host.example.com groupadd[14803]: new group: name=printadmin, GID=991 sh]# cat /etc/nsswitch.conf | grep -v "^#" passwd: sss files systemd group: sss files systemd netgroup: sss files automount: sss files services: sss files sudoers: files sss shadow: files sss hosts: files dns myhostname bootparams: files ethers: files netmasks: files networks: files protocols: files rpc: files publickey: files aliases: files I will try to prepare minimal reproducer.
Could it be something from the systemd nsswitch module? Could you try to somehow reproduce the problem without the systemd module in the nsswitch?
It is not related to systemd. As I mentioned I cannot easily reproduce on minimal system Just from beaker lib test. I cannot see AVC in following case. + eval cat '/etc/nsswitch.conf;' yum install -y samba-common ++ cat /etc/nsswitch.conf ++ yum install -y samba-common # # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files in /etc # db Use the pre-processed /var/db files # compat Use /etc files plus *_compat pseudo-databases # hesiod Use Hesiod (DNS) for user lookups # sss Use sssd (System Security Services Daemon) # [NOTFOUND=return] Stop searching if not found so far # # 'sssd' performs its own 'files'-based caching, so it should # generally come before 'files'. # # WARNING: Running nscd with a secondary caching service like sssd may lead to # unexpected behaviour, especially with how long entries are cached. # To use 'db', install the nss_db package, and put the 'db' in front # of 'files' for entries you want to be looked up first in the # databases, like this: # # passwd: db files # shadow: db files # group: db files passwd: sss files systemd shadow: files sss group: sss files systemd hosts: files dns myhostname bootparams: files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: sss publickey: files automount: files sss aliases: files Last metadata expiration check: 0:02:46 ago on Mon 23 Sep 2019 07:18:03 PM EDT. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: samba-common noarch 2:4.11.0-3.fc31 beaker-Fedora-Everything 142 k Transaction Summary ================================================================================ Install 1 Package Total download size: 142 k Installed size: 130 k Downloading Packages: samba-common-4.11.0-3.fc31.noarch.rpm 16 MB/s | 142 kB 00:00 -------------------------------------------------------------------------------- Total 14 MB/s | 142 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Running scriptlet: samba-common-2:4.11.0-3.fc31.noarch 1/1 Installing : samba-common-2:4.11.0-3.fc31.noarch 1/1 Running scriptlet: samba-common-2:4.11.0-3.fc31.noarch 1/1 Verifying : samba-common-2:4.11.0-3.fc31.noarch 1/1 Installed: samba-common-2:4.11.0-3.fc31.noarch Complete!
Do you have some another idea for troubleshooting? Do you know what could cause "pipe communication between groupadd_t:s0 and unconfined_service_t:s0?
As I already said - the only cause could be in one of the nsswitch modules - either sss or systemd. It would be interesting to obtain a strace output from the groupadd command that encounters the AVC. However if the only case where this happens is during an install/update transaction I am afraid that obtaining a reasonable strace would be very hard.
Lets play a neeinfo game :-) There is obviously issue with pipe `comm="groupadd" path="pipe:[55116]" dev="pipefs" ino=55116` based on audit log. Checking inode does not help to find out consumer on the second end of pipe. cause such inode does not exist after AVC. You should probably know the code better. Could you try to collect all usage of pipe in groupadd ? And as ai already mentioned it happen even when sss_cache is removed from filesystem.
Maybe I was not clear enough - there is no pipe usage in groupadd itself. That's why I am saying that the cause can be only in one of the nsswitch modules that are configured in /etc/nsswitch.conf. As I cannot reproduce the issue I can only recommend you to try to modify the /etc/nsswitch.conf and see whether removal of some nsswitch module will help mitigating the issue. Then please reassign the issue to the respective package that owns the module.
(In reply to Tomas Mraz from comment #14) > Maybe I was not clear enough - there is no pipe usage in groupadd itself. > That's why I am saying that the cause can be only in one of the nsswitch > modules that are configured in /etc/nsswitch.conf. As I cannot reproduce the > issue I can only recommend you to try to modify the /etc/nsswitch.conf and > see whether removal of some nsswitch module will help mitigating the issue. > Then please reassign the issue to the respective package that owns the > module. hmm, sh$ rpm -q sssd-client package sssd-client is not installed sh$ cat /etc/nsswitch.conf | grep "^[^#]" passwd: files shadow: files sss group: files hosts: files dns myhostname bootparams: files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: sss publickey: files automount: files sss aliases: file It cannot be caused by sssd because it was not installed. Are there some `hosts`/`initgroups` related operations ? Could you recommend simper nsswitch.conf ?
I played a little bit with SELinux and the unconfined_service_t is restraintd time->Mon Oct 7 11:31:00 2019 type=AVC msg=audit(1570462260.046:403): avc: denied { read } for pid=11531 comm="groupadd" path="pipe:[38748]" dev="pipefs" ino=38748 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:restraint_t:s0 tclass=fifo_file permissive=1 ---- time->Mon Oct 7 11:31:00 2019 type=AVC msg=audit(1570462260.063:404): avc: denied { ioctl } for pid=11531 comm="groupadd" path="pipe:[38748]" dev="pipefs" ino=38748 ioctlcmd=0x5401 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:system_r:restraint_t:s0 tclass=fifo_file permissive=1 Martin, could you try to explain how can yum(and thus scriptlets -> groupadd) use pipe with restraint daemon?
Then it could be a leaked file descriptor from the parent process that calls groupadd?
(In reply to Tomas Mraz from comment #17) > Then it could be a leaked file descriptor from the parent process that calls > groupadd? But why groupadd would try to read anything from leaked file descriptor ? I could imagine closing file descriptors but read ?
I am sorry but without at least a strace I have really no idea. Maybe if the fd was the stdin? There is simply nothing in the groupadd code that would do ioctl() (unless under the hoods of some glibc library calls but I do not really see which one could that be).
*** Bug 1759932 has been marked as a duplicate of this bug. ***
restraintd runs as unconfined_service_t sh# ps auxZ | grep restrain[t] system_u:system_r:unconfined_service_t:s0 root 836 0.0 0.0 233000 7284 ? Ssl Oct15 0:20 /usr/bin/restraintd When dnf is executed from beakerlib test it is still executed as unconfined_service_t becasue there is not any transition rule (IIUC) So dnf needs to run rpm scriptlets and it looks like it create pipes (probably stdin). And groupadd is always executed with groupadd_t context. It was introduced in selinux-policy-3.14.4-32.fc31 and rpm changelog for that version says: """ - Remove allowing all domain to communicate over pipes with all domain under rpm_transition_domain attribute """ I cannot see AVC after downgrading to elinux-policy-3.14.4-31.fc31
Lukas, I assume you d not want to revert tat change. Whad do you suggest here?
*** Bug 1763877 has been marked as a duplicate of this bug. ***
commit 6275b462ee199fbad56e6cb839cce857c8f609a8 (HEAD -> rawhide) Author: Lukas Vrabec <lvrabec> Date: Thu Oct 24 14:47:58 2019 +0200 Dontaudit domains read/write leaked pipes Dontaudit all domains to read/write leaked unconfined_service_t domains unnamed pipes Resolves: rhbz#1754219
FEDORA-2019-7d65c50fd6 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-7d65c50fd6
selinux-policy-3.14.4-39.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-7d65c50fd6
selinux-policy-3.14.4-39.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1774592 has been marked as a duplicate of this bug. ***