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@gmail.com 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.