Description of problem: SELinux is preventing systemd-user-ru from 'unlink' accesses on the lnk_file user. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-user-ru should be allowed unlink access on the user lnk_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 'systemd-user-ru' --raw | audit2allow -M my-systemduserru # semodule -X 300 -i my-systemduserru.pp Additional Information: Source Context system_u:system_r:systemd_logind_t:s0 Target Context unconfined_u:object_r:config_home_t:s0 Target Objects user [ lnk_file ] Source systemd-user-ru Source Path systemd-user-ru Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-34.22-1.fc34.noarch Local Policy RPM selinux-policy-targeted-34.22-1.fc34.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.14.16-201.fc34.x86_64 #1 SMP Wed Nov 3 13:57:29 UTC 2021 x86_64 x86_64 Alert Count 1 First Seen 2021-11-07 23:18:07 CET Last Seen 2021-11-07 23:18:07 CET Local ID 9f27ed7f-1d9d-4842-a77f-104593e16603 Raw Audit Messages type=AVC msg=audit(1636323487.207:363): avc: denied { unlink } for pid=12431 comm="systemd-user-ru" name="user" dev="tmpfs" ino=143 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=lnk_file permissive=0 Hash: systemd-user-ru,systemd_logind_t,config_home_t,lnk_file,unlink Version-Release number of selected component: selinux-policy-targeted-34.22-1.fc34.noarch Additional info: component: selinux-policy reporter: libreport-2.15.2 hashmarkername: setroubleshoot kernel: 5.14.16-201.fc34.x86_64 type: libreport Potential duplicate: bug 1909344
In Cockpit's CI we see this for Fedora 35 as well now [1], for selinux-policy (34.22-1.fc34 -> 34.23-1.fc34) That and kernel-core (5.15.12-100.fc34 -> 5.15.13-100.fc34) are the only relevant updates to that image which could have caused that, the few other package updates [2] are unrelated. In particular, systemd did *not* get updated. [1] https://github.com/cockpit-project/bots/pull/2785 [2] https://logs.cockpit-project.org/logs/image-refresh-2785-20220110-022222/log scroll to the bottom
> we see this for Fedora 35 as well Sorry, this was supposed to be "34" of course.
I am experiencing a similar issue (difficult to say if it is the same described here or not). From time to time a selinux notification shows up saying that systemd-user-ru is not allowed to access "unlink" on sock_file bus. Appart from the notification, I cannot see anything else going wrong. I copy/paste the selinux notice (sorry it is in Spanish): This has started to appear after some update (I cannot remember which packages were updated at that moment). SELinux está negando a systemd-user-ru de unlink el acceso a sock_file bus. ***** El complemento catchall (100. confidence) sugiere********************** Si cree que de manera predeterminada se debería permitir a systemd-user-ru el acceso unlink sobre bus sock_file. Entoncesdebería reportar esto como un error. Puede generar un módulo de política local para permitir este acceso. Hacer permita el acceso temporalmente ejecutando: # ausearch -c 'systemd-user-ru' --raw | audit2allow -M mi-systemduserru # semodule -X 300 -i mi-systemduserru.pp Información adicional: Contexto de origen system_u:system_r:systemd_logind_t:s0 Contexto Destino unconfined_u:object_r:session_dbusd_tmp_t:s0 Objetos Destino bus [ sock_file ] Origen systemd-user-ru Dirección de origen systemd-user-ru Puerto <Desconocido> Nombre de Equipo migelinho.ugr.es Paquetes RPM Fuentes Paquetes RPM Destinos SELinux Policy RPM selinux-policy-targeted-34.23-1.fc34.noarch Local Policy RPM selinux-policy-targeted-34.23-1.fc34.noarch SELinux activado True Tipo de política targeted Modo impositivo Enforcing Nombre de equipo migelinho.ugr.es Plataforma Linux migelinho.ugr.es 5.15.12-100.fc34.x86_64 #1 SMP Wed Dec 29 15:21:44 UTC 2021 x86_64 x86_64 Cantidad de alertas 16 Visto por primera vez 2022-01-12 09:02:18 CET Visto por última vez 2022-01-13 09:02:18 CET ID local 775e0fcf-481f-4a1f-b9ef-d9c06ff905f8 Mensajes raw de aviso type=AVC msg=audit(1642060938.636:315): avc: denied { unlink } for pid=9394 comm="systemd-user-ru" name="bus" dev="tmpfs" ino=56 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=unconfined_u:object_r:session_dbusd_tmp_t:s0 tclass=sock_file permissive=0 Hash: systemd-user-ru,systemd_logind_t,session_dbusd_tmp_t,sock_file,unlink
I am receiving similar reports not only from systemd-user-ru but also from other sources, for example lightdm-gtk-greeting or atril-thumbnail, so I infer that the problem does not lie in these applications but in selinux itself.
*** Bug 2039388 has been marked as a duplicate of this bug. ***
Can someone help me to trigger the original issue? I'd like to see it with full audit enabled type=AVC msg=audit(1636323487.207:363): avc: denied { unlink } for pid=12431 comm="systemd-user-ru" name="user" dev="tmpfs" ino=143 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=lnk_file permissive=0 Or send me a result of the following change: 1) Open the /etc/audit/rules.d/audit.rules file in an editor. 2) Remove the following line if it exists: -a task,never 3) Add the following line to the end of the file: -w /etc/shadow -p w 4) Restart the audit daemon: # service auditd restart 5) Re-run your scenario. 6) Collect AVC denials: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today The others with session_dbusd_tmp_t are not related and should already be addressed.
Created attachment 1852611 [details] ausearch output
What is interesting is that some of the SELinux alerts did not happen until I mounted an external drive and tried to access files on that drive
@pgaltieri thank you, these denials are already addressed but there is no config_home_t like in the original report
*** Bug 2044100 has been marked as a duplicate of this bug. ***
The only way I have been able to trigger this issue is to mount an external drive (in my case NTFS) and then reboot the system. The alert shows up as soon as you login. Here's the AVC type=AVC msg=audit(01/24/2022 07:51:10.178:288) : avc: denied { unlink } for pid=3778 comm=systemd-user-ru name=bus dev="tmpfs" ino=60 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=unconfined_u:object_r:session_dbusd_tmp_t:s0 tclass=sock_file permissive=0
I began seeing this last Wednesday, Jan. 19th. with sock_file bus as the target. In my specific case, the denial occurs every half hour at the top of the hour and the 30 minute mark. My AVC denial: SELinux is preventing systemd-user-ru from unlink access on the sock_file bus. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-user-ru should be allowed unlink access on the bus 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 'systemd-user-ru' --raw | audit2allow -M my-systemduserru # semodule -X 300 -i my-systemduserru.pp Additional Information: Source Context system_u:system_r:systemd_logind_t:s0 Target Context unconfined_u:object_r:session_dbusd_tmp_t:s0 Target Objects bus [ sock_file ] Source systemd-user-ru Source Path systemd-user-ru Port <Unknown> Host vega.home.local Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-34.23-1.fc34.noarch Local Policy RPM selinux-policy-targeted-34.23-1.fc34.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name vega.home.local Platform Linux vega.home.local 5.15.14-100.fc34.x86_64 #1 SMP Tue Jan 11 16:53:51 UTC 2022 x86_64 x86_64 Alert Count 12 First Seen 2022-01-18 23:51:36 EST Last Seen 2022-01-24 19:00:12 EST Local ID d5c359fa-fd36-45ea-ad6f-fd5ec62538fb Raw Audit Messages type=AVC msg=audit(1643068812.104:740): avc: denied { unlink } for pid=36620 comm="systemd-user-ru" name="bus" dev="tmpfs" ino=2534 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=unconfined_u:object_r:session_dbusd_tmp_t:s0 tclass=sock_file permissive=0 Hash: systemd-user-ru,systemd_logind_t,session_dbusd_tmp_t,sock_file,unlink
I confirm the report by rickpohly. The selinux notification regarding systemd-user-ru appears every "o'clock" and "half past" hour with exactly the same sympthoms described there.
As told above, I see messages of the same kind regarding atril-thumbnail. I have seen that these notifications tend to appear when manipulating (creating, copying, ...) PDF files. I copy paste the information of selinux when the error is triggered by atril-thumbnail (sorry it is in Spanish, I expect you can figure out the English translation). SELinux está negando a atril-thumbnail de write el acceso a sock_file bus. ***** El complemento catchall (100. confidence) sugiere********************** Si cree que de manera predeterminada se debería permitir a atril-thumbnail el acceso write sobre bus sock_file. Entoncesdebería reportar esto como un error. Puede generar un módulo de política local para permitir este acceso. Hacer permita el acceso temporalmente ejecutando: # ausearch -c 'atril-thumbnail' --raw | audit2allow -M mi-atrilthumbnail # semodule -X 300 -i mi-atrilthumbnail.pp Información adicional: Contexto de origen unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 Contexto Destino unconfined_u:object_r:session_dbusd_tmp_t:s0 Objetos Destino bus [ sock_file ] Origen atril-thumbnail Dirección de origen atril-thumbnail Puerto <Desconocido> Nombre de Equipo migelinho.ugr.es Paquetes RPM Fuentes Paquetes RPM Destinos SELinux Policy RPM selinux-policy-targeted-34.23-1.fc34.noarch Local Policy RPM selinux-policy-targeted-34.23-1.fc34.noarch SELinux activado True Tipo de política targeted Modo impositivo Enforcing Nombre de equipo migelinho.ugr.es
FEDORA-2022-35e911cda6 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-35e911cda6
FEDORA-2022-35e911cda6 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-35e911cda6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-35e911cda6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I have installed the suggested update, rebooted the system and, in an hour or so, no selinux alert has appeared. At first sight, it looks like the problem may have been solved.
FEDORA-2022-35e911cda6 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.