Created attachment 2064464 [details]
File: description

Created attachment 2064465 [details]
File: os_info

SELinux is preventing systemd-coredum from using the sys_admin capability.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that systemd-coredum should have the sys_admin capability 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-coredum' --raw | audit2allow -M my-systemdcoredum
# semodule -X 300 -i my-systemdcoredum.pp

Additional Information:
Source Context                system_u:system_r:systemd_coredump_t:s0
Target Context                system_u:system_r:systemd_coredump_t:s0
Target Objects                Unknown [ capability ]
Source                        systemd-coredum
Source Path                   systemd-coredum
Port                          <Unknown>
Host                          grumpey1
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-41.27-1.fc41.noarch
Local Policy RPM              selinux-policy-targeted-41.27-1.fc41.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     grumpey1
Platform                      Linux grumpey1 6.12.7-200.fc41.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Fri Dec 27 17:05:33 UTC 2024
                              x86_64
Alert Count                   1
First Seen                    2025-01-03 17:48:20 EST
Last Seen                     2025-01-03 17:48:20 EST
Local ID                      bcb5e6ad-b9a8-4182-9740-06319f73c536

Raw Audit Messages
type=AVC msg=audit(1735944500.351:438): avc:  denied  { sys_admin } for  pid=74167 comm="systemd-coredum" capability=21  scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:system_r:systemd_coredump_t:s0 tclass=capability permissive=0


Hash: systemd-coredum,systemd_coredump_t,systemd_coredump_t,capability,sys_admin

selinux-policy-41.27-1.fc41

Hi,

Do you happen to know which change is needed to trigger this issue?
Please include output of:

mount
systemd-analyze cat-config systemd/coredump.conf

Full auditing can help to gather more information, but may not be enough:
https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing

You can also try to grab the complete trace, just note it requires some effort:
https://fedoraproject.org/wiki/SELinux/Debugging#Using_perf_to_trace_all_system_denials
https://fedoraproject.org/wiki/SELinux/Debugging#Interpret_data_gathered_by_perf

This looks like it occurs when launching games from steam. Steam is installed as a flatpak. 

Mon 2025-01-13 21:44:29 EST  6221 1000 1002 SIGTRAP present  /home/grumpey/.var/app/com.valvesoftware.Steam/.local/share/Steam/ubuntu12_64/steamwebhelper

output of: 
mount: 
/dev/mapper/luks-5a26a62f-0a55-4b72-a775-85e89c240c97 on / type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=259,subvol=/@)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=4096k,nr_inodes=3943492,mode=755,inode64)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime,seclabel)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,size=6315728k,nr_inodes=819200,mode=755,inode64)
tmpfs on /run/credentials/systemd-cryptsetup@luks\x2d5a26a62f\x2d0a55\x2d4b72\x2da775\x2d85e89c240c97.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,nosuid,noexec,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=7517)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,seclabel,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime,seclabel)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime,seclabel)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime,seclabel)
tmpfs on /run/credentials/systemd-journald.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
tmpfs on /run/credentials/systemd-network-generator.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
tmpfs on /run/credentials/systemd-udev-load-credentials.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/credentials/systemd-tmpfiles-setup-dev-early.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
tmpfs on /run/credentials/systemd-sysctl.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
tmpfs on /run/credentials/systemd-tmpfiles-setup-dev.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
systemd-1 on /srv/public type autofs (rw,relatime,fd=60,pgrp=1,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=8749)
systemd-1 on /srv/storage/books type autofs (rw,relatime,fd=66,pgrp=1,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=17476)
systemd-1 on /srv/storage/documents type autofs (rw,relatime,fd=67,pgrp=1,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=17479)
systemd-1 on /srv/storage/games type autofs (rw,relatime,fd=68,pgrp=1,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=17481)
systemd-1 on /srv/storage/linux type autofs (rw,relatime,fd=69,pgrp=1,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=8752)
systemd-1 on /srv/storage/movies type autofs (rw,relatime,fd=70,pgrp=1,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=8755)
systemd-1 on /srv/storage/music type autofs (rw,relatime,fd=72,pgrp=1,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=8758)
systemd-1 on /srv/storage/pictures type autofs (rw,relatime,fd=73,pgrp=1,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=8761)
systemd-1 on /srv/storage/susan type autofs (rw,relatime,fd=74,pgrp=1,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=8764)
/dev/mapper/luks-5a26a62f-0a55-4b72-a775-85e89c240c97 on /home type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=258,subvol=/@home)
/dev/mapper/luks-5a26a62f-0a55-4b72-a775-85e89c240c97 on /snapshots type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/@snapshots)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,seclabel,size=15789320k,nr_inodes=1048576,inode64)
/dev/mapper/luks-5a26a62f-0a55-4b72-a775-85e89c240c97 on /var type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/@var)
/dev/nvme0n1p2 on /boot type ext4 (rw,relatime,seclabel)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/credentials/systemd-tmpfiles-setup.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
tmpfs on /run/credentials/systemd-resolved.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/credentials/systemd-vconsole-setup.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=3157860k,nr_inodes=789465,mode=700,uid=1000,gid=1002,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1002)
XX.XX.23.100:/srv/storage/documents on /srv/storage/documents type nfs4 (rw,nosuid,nodev,noexec,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=XX.XX.23.103,local_lock=none,addr=XX.XX.23.100,_netdev,user,x-systemd.automount,x-systemd.mount-timeout=10,x-systemd.idle-timeout=5min)

 
systemd-analyze cat-config systemd/coredump.conf:
# /usr/lib/systemd/coredump.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file (or a copy of it placed in
# /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/coredump.conf.d/ directory. The latter is generally
# recommended. Defaults can be restored by simply deleting the main
# configuration file and all drop-ins located in /etc/.
#
# Use 'systemd-analyze cat-config systemd/coredump.conf' to display the full config.
#
# See coredump.conf(5) for details.

[Coredump]
#Storage=external
#Compress=yes
# On 32-bit, the default is 1G instead of 32G.
#ProcessSizeMax=32G
#ExternalSizeMax=32G
#JournalSizeMax=767M
#MaxUse=
#KeepFree=

I performed the following steps: I logged into Gnome and downloaded KDE, then I restarted the computer and logged into KDE. I changed the theme to dark.
I installed Vivaldi and Steam, and within it, the game Outer Wilds, which I then launched. There was no image displayed in the main menu, so I thought I needed NVIDIA drivers. I then installed akmod-nvidia and restarted the computer. Everything was fine up to the login screen, but after logging in, the system started to lag heavily and run with a delay; it was difficult even to type commands into the terminal. I found an answer online that NVIDIA drivers conflict with Wayland, so I uninstalled them. I restarted the computer, and everything worked smoothly again. I spent some time browsing the internet and then shut down the computer.
The next day, I turned it on, and everything still worked, but in the File Explorer, updates reappeared after logging in – about 1.3GB. I downloaded them and performed the required restart.
After restarting, everything started lagging again. With the help of ChatGPT, I checked the installed drivers, cleared any potential dependencies left after NVIDIA, checked for missing dependencies of installed packages, reinstalled Wayland, and restarted the computer. Unfortunately, it didn't help, and it continued to lag. But then I noticed the option to boot the system with previous kernel versions and recovery mode. I checked them all one by one, and in the previous kernels, the system also lagged, while in recovery mode, it worked correctly. I continued searching for the cause, installing current updates, verifying system files, but this only made things worse because at one point, the system would only boot into text mode. I kept trying to fix it until I finally discovered that the system was trying to read a .desktop file that was not in its location. After many attempts, I managed to find and install the package that contained it. The system did start booting, but only into Gnome; the KDE selection and other Gnome variants disappeared; there was no cogwheel icon on the login screen at all. Moreover, after logging in, the colors looked strange, as if the color palette or bit depth had been reduced. Unfortunately, no system program would launch despite multiple attempts. When the cursor was on the wallpaper, it didn't indicate any activity, but as soon as I moved it to the top bar (the one with the date and time), a loading icon appeared, which disappeared after a moment. The terminal, settings, and file explorer didn't work, but surprisingly, Firefox did. At this stage, even recovery mode no longer restored the system to proper functioning.

I performed the following steps: I logged into Gnome and downloaded KDE, then I restarted the computer and logged into KDE. I changed the theme to dark.
I installed Vivaldi and Steam, and within it, the game Outer Wilds, which I then launched. There was no image displayed in the main menu, so I thought I needed NVIDIA drivers. I then installed akmod-nvidia and restarted the computer. Everything was fine up to the login screen, but after logging in, the system started to lag heavily and run with a delay; it was difficult even to type commands into the terminal. I found an answer online that NVIDIA drivers conflict with Wayland, so I uninstalled them. I restarted the computer, and everything worked smoothly again. I spent some time browsing the internet and then shut down the computer.
The next day, I turned it on, and everything still worked, but in the File Explorer, updates reappeared after logging in – about 1.3GB. I downloaded them and performed the required restart.
After restarting, everything started lagging again. With the help of ChatGPT, I checked the installed drivers, cleared any potential dependencies left after NVIDIA, checked for missing dependencies of installed packages, reinstalled Wayland, and restarted the computer. Unfortunately, it didn't help, and it continued to lag. But then I noticed the option to boot the system with previous kernel versions and recovery mode. I checked them all one by one, and in the previous kernels, the system also lagged, while in recovery mode, it worked correctly. I continued searching for the cause, installing current updates, verifying system files, but this only made things worse because at one point, the system would only boot into text mode. I kept trying to fix it until I finally discovered that the system was trying to read a .desktop file that was not in its location. After many attempts, I managed to find and install the package that contained it. The system did start booting, but only into Gnome; the KDE selection and other Gnome variants disappeared; there was no cogwheel icon on the login screen at all. Moreover, after logging in, the colors looked strange, as if the color palette or bit depth had been reduced. Unfortunately, no system program would launch despite multiple attempts. When the cursor was on the wallpaper, it didn't indicate any activity, but as soon as I moved it to the top bar (the one with the date and time), a loading icon appeared, which disappeared after a moment. The terminal, settings, and file explorer didn't work, but surprisingly, Firefox did. At this stage, even recovery mode no longer restored the system to proper functioning.

*** Bug 2338995 has been marked as a duplicate of this bug. ***

*** Bug 2338954 has been marked as a duplicate of this bug. ***

*** Bug 2338864 has been marked as a duplicate of this bug. ***

*** Bug 2338755 has been marked as a duplicate of this bug. ***

*** Bug 2338719 has been marked as a duplicate of this bug. ***

*** Bug 2338715 has been marked as a duplicate of this bug. ***

*** Bug 2337154 has been marked as a duplicate of this bug. ***

*** Bug 2336500 has been marked as a duplicate of this bug. ***

*** Bug 2335828 has been marked as a duplicate of this bug. ***

*** Bug 2335669 has been marked as a duplicate of this bug. ***

*** Bug 2335668 has been marked as a duplicate of this bug. ***

*** Bug 2335658 has been marked as a duplicate of this bug. ***

*** Bug 2335554 has been marked as a duplicate of this bug. ***

*** Bug 2334966 has been marked as a duplicate of this bug. ***

*** Bug 2334875 has been marked as a duplicate of this bug. ***

*** Bug 2334836 has been marked as a duplicate of this bug. ***

*** Bug 2334802 has been marked as a duplicate of this bug. ***

*** Bug 2334228 has been marked as a duplicate of this bug. ***

*** Bug 2334204 has been marked as a duplicate of this bug. ***

*** Bug 2334020 has been marked as a duplicate of this bug. ***

*** Bug 2333836 has been marked as a duplicate of this bug. ***

*** Bug 2333828 has been marked as a duplicate of this bug. ***

*** Bug 2333820 has been marked as a duplicate of this bug. ***

*** Bug 2304168 has been marked as a duplicate of this bug. ***

*** Bug 2338634 has been marked as a duplicate of this bug. ***

*** Bug 2336529 has been marked as a duplicate of this bug. ***

*** Bug 2336344 has been marked as a duplicate of this bug. ***

I still cannot reproduce it and from all duplicates I can only gather these description items:

Woke after closing laptop lid
This error occasionally occurs when closing flatpak applications 
Randomly appears when I closing some flatpak applications (for example: Mission Center)
it poped up after i ran a upgrade
I turn on my computer, on GDM I shut down without login in. Then turn on, login in into my account using a gnome x11 session, used Firefox for a bit, and this happened. Maybe unrelated to my steps, pretty random.
This seems to be an issue with Flatpak.
As far as I have noticed is regularily occurs with Spotify, and just recently occurred while trying to use the Flatpak for Unity Hub.
This appears to happen every time systemd-coredumpctl / ABRT attempt to process a crash report.
This occured twice while launching steam but I don't know how to reproduce it. 
fedora systemd-coredump[10963]: Process 8722 (steamwebhelper) of user 1000 terminated abnormally with signal 4/ILL, 
flatpak spotify was working in the backgound, system started gradualy falling into sleeping state, so I moved mouse - this is when error appeared
I've booted to system as always, performed system update and this message popped up after reboot
flatpak app crashed, then I got an AVC denial
The user attempts to close Rhythmbox for the first time.During this process, Rhythmbox crashes unexpectedly, which may trigger the system to generate a core dump for debugging purposes. 
I installed an application via flatpack which crashed immediately on startup, resulting in this issue. This is reproducible across different applications crashing.
open OBS Studio, add screen capture (pipewire) and give permission for screen sharing (any option full screen or window) in system window

If I kill any application with SEGV, ILL, or ABRT, I can see no denial.
The same behaviour on F41 and F42.

I wrote "Woke after closing laptop lid", but actually the problem really may be in flatpak apps. When I close my laptop lid it disconnects from network and Mikrotik's Winbox flatpak crashes (it always crashes when it can't reach the router). Then abrt-applet notification appears along with this SELinux error

> the problem really may be in flatpak apps

Unlikely, as I had that randomly occur once upon exiting Steam, which was installed from RPM Fusion via dnf5. (I no longer have the logs, unfortunately.)

As far as I can tell, this happens every time there's a coredump that is getting processed.

I tried relabeling my entire system, and the SELinux alert persists.

(In reply to Fabio Valentini from comment #38)
> As far as I can tell, this happens every time there's a coredump that is
> getting processed.
> 
> I tried relabeling my entire system, and the SELinux alert persists.


Fabio, can you post exact systemd and selinux-policy versions where you see this AVC occurring every time, thanks! Btw, I was trying to reproduce on fresh instal of F41 Workstation (systemd-256.7-1, selinux-policy-41.20) but had no luck.

I just had another alert like this pop up today, with

selinux-policy-targeted-41.29-1.fc41.noarch
systemd-256.11-1.fc41.x86_64

(In reply to Fabio Valentini from comment #40)
> I just had another alert like this pop up today, with
> 
> selinux-policy-targeted-41.29-1.fc41.noarch
> systemd-256.11-1.fc41.x86_64

Interesting, I've just booted F41 with the same versions of systemd and selinux-policy and I can't reproduce. Any chance you could install corresponding debuginfo packages for systemd and then run following perf command while reproducing AVC?

perf record -a -g -e avc:selinux_audited

After you hit AVC denial you can C-c perf and run "perf script" command in the directory where you have perf.data. Then we should see exact stacktrace which leads to AVC.

It took a few dozens of attempts to dump a core, generate an AVC, and track it with perf after killing spotify/flatpak by SIGILL.

systemd-coredum   21347 [000] 14920.883259: avc:selinux_audited: requested=0x200000 den>
        ffffffff91784236 avc_audit_post_callback+0x216 ([kernel.kallsyms])
        ffffffff91784236 avc_audit_post_callback+0x216 ([kernel.kallsyms])
        ffffffff917af951 common_lsm_audit+0x2b1 ([kernel.kallsyms])
        ffffffff91785533 slow_avc_audit+0xb3 ([kernel.kallsyms])
        ffffffff9178ac54 cred_has_capability.isra.0+0x114 ([kernel.kallsyms])
        ffffffff917767f0 security_capable+0x70 ([kernel.kallsyms])
        ffffffff910ff5d2 capable+0x32 ([kernel.kallsyms])
        ffffffff91508a11 xattr_permission+0xf1 ([kernel.kallsyms])
        ffffffff91508a95 vfs_getxattr+0x45 ([kernel.kallsyms])
        ffffffff91509d44 do_getxattr+0x74 ([kernel.kallsyms])
        ffffffff91509ee1 getxattr+0x91 ([kernel.kallsyms])
        ffffffff91509fac path_getxattr+0x7c ([kernel.kallsyms])
        ffffffff9220b262 do_syscall_64+0x82 ([kernel.kallsyms])
        ffffffff9240012f entry_SYSCALL_64_after_hwframe+0x76 ([kernel.kallsyms])
            7fc2296fca3e lgetxattr+0xe (/usr/lib64/libc.so.6)
            7fc229a2577e getxattr_at_malloc+0x1be (/usr/lib64/systemd/libsystemd-shared>
            7fc229a2646e getxattr_at_bool+0x2e (/usr/lib64/systemd/libsystemd-shared-25>
            7fc2299ab7a4 cg_get_xattr_bool+0x64 (/usr/lib64/systemd/libsystemd-shared-2>
            7fc2299ab864 cg_is_delegated+0x24 (/usr/lib64/systemd/libsystemd-shared-256>
            55f7745482d9 [unknown] (/usr/lib/systemd/systemd-coredump)

The complete audit entry:
type=PROCTITLE msg=audit(01/22/2025 17:10:46.879:818) : proctitle=/usr/lib/systemd/systemd-coredump 20554 1000 1000 4 1737562246 18446744073709551615 localhost-live 
type=PATH msg=audit(01/22/2025 17:10:46.879:818) : item=0 name=/sys/fs/cgroup/user.slice/user-1000.slice/user inode=7948 dev=00:1b mode=dir,755 ouid=user1 ogid=user1 rdev=00:00 obj=system_u:object_r:cgroup_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(01/22/2025 17:10:46.879:818) : cwd=/ 
type=SYSCALL msg=audit(01/22/2025 17:10:46.879:818) : arch=x86_64 syscall=lgetxattr success=no exit=ENODATA(No data available) a0=0x55f7839bd400 a1=0x7fc229b4610f a2=0x55f7839b7770 a3=0x67 items=1 ppid=2 pid=21347 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-coredum exe=/usr/lib/systemd/systemd-coredump subj=system_u:system_r:systemd_coredump_t:s0 key=(null) 
type=AVC msg=audit(01/22/2025 17:10:46.879:818) : avc:  denied  { sys_admin } for  pid=21347 comm=systemd-coredum capability=sys_admin  scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:system_r:systemd_coredump_t:s0 tclass=capability permissive=0 

# stat /sys/fs/cgroup/user.slice/user-1000.slice/user
  File: /sys/fs/cgroup/user.slice/user-1000.slice/user
  Size: 0               Blocks: 0          IO Block: 4096   directory
Device: 0,27    Inode: 7948        Links: 7
Access: (0755/drwxr-xr-x)  Uid: ( 1000/   user1)   Gid: ( 1000/   user1)
Context: system_u:object_r:cgroup_t:s0
Access: 2025-01-22 13:03:07.878199740 +0100
Modify: 2025-01-22 13:03:08.563419706 +0100
Change: 2025-01-22 13:03:08.563419706 +0100
 Birth: -

capabilities(7) did not give me a hint as why the capability is needed.

# coredumpctl dump
           PID: 20135 (spotify)
           UID: 1000 (user1)
           GID: 1000 (user1)
        Signal: 11 (SEGV)
     Timestamp: Wed 2025-01-22 17:18:46 CET (5min ago)
  Command Line: $'/app/extra/share/spotify/spotify --type=zygote --no-zygote-sandbox --no-sandbox --string-annotations --enable-crash-reporter=, --change-stack-guard-on-fork=enable --user-data-dir=/home/user1/.var/app/com.spotify.Client/cache/spotify --log-severity=disable --user-agent-product=Chrome/129.0.6668.90 Spotify/1.2.50.335'
    Executable: /app/extra/share/spotify/spotify
 Control Group: /user.slice/user-1000.slice/user/app.slice/app-flatpak-com.spotify.Client-20114.scope
          Unit: user
     User Unit: app-flatpak-com.spotify.Client-20114.scope
         Slice: user-1000.slice
     Owner UID: 1000 (user1)
       Boot ID: 81b4e879ad634b5296a96b1ea2054b20
    Machine ID: 3c9e9fc94a1a42cca7b57d082de2c40b
      Hostname: localhost-live
       Storage: /var/lib/systemd/coredump/core.spotify.1000.81b4e879ad634b5296a96b1ea2054b20.20135.1737562726000000.zst (present)
  Size on Disk: 4.7M
       Message: Process 20135 (spotify) of user 1000 dumped core.
                
                Stack trace of thread 10:
                #0  0x00007fd869f39280 n/a (n/a + 0x0)
                #1  0x00007fd8717b59bf n/a (n/a + 0x0)
                #2  0x00007fd8717b90ba n/a (n/a + 0x0)
                #3  0x00007fd8717b330d n/a (n/a + 0x0)
                #4  0x00007fd8717b3e93 n/a (n/a + 0x0)
                #5  0x00007fd8717b4e25 n/a (n/a + 0x0)
                #6  0x00007fd8717b2f23 n/a (n/a + 0x0)
                #7  0x00007fd86db2b63b n/a (n/a + 0x0)
                #8  0x00007fd86db14b67 n/a (n/a + 0x0)
                #9  0x00007fd86da89e41 n/a (n/a + 0x0)
                #10 0x000055eb3611dfb3 n/a (n/a + 0x0)
                ELF object binary architecture: AMD x86-64

I managed to trigger this again. I'll upload the output of "perf script" as an attachment.

Funnily enough, my crash is also from Spotify :)
Is it possible that the problem is from coredumps that happen in flatpak apps?

Created attachment 2073653 [details]
output of "perf script"

(In reply to Fabio Valentini from comment #43)
> Is it possible that the problem is from coredumps that happen in flatpak
> apps?

I just had a flatpak application crash, then I got this SELinux problem (ABRT mentioned bug #2264997, but thanks to people linking bugs to each other, I found my way here).

A look at the syslog on two machines shows that the problem repeatedly occurs with different flatpak applications, but I have only seen it happening after a coredump in a flatpak application, not after any other crashes.

I see this problem every time I quit Joplin which is installed as a flatpak on F41.

IIRC, at one point, crashes in flatpak were just ignored by abrt.  I remember being disappointed at first, but then I decided that was a reasonable choice.  Either I'm remembering it wrong, or that rule has changed or was broken.

I think this symptom with coredum(p) only happens with flatpak apps; at least that is my experience. However, that doesn't mean the root cause only affects flatpak apps.

(In reply to Zdenek Pytela from comment #42)
> It took a few dozens of attempts to dump a core, generate an AVC, and track
> it with perf after killing spotify/flatpak by SIGILL.
> 
> systemd-coredum   21347 [000] 14920.883259: avc:selinux_audited:
> requested=0x200000 den>
>         ffffffff91784236 avc_audit_post_callback+0x216 ([kernel.kallsyms])
>         ffffffff91784236 avc_audit_post_callback+0x216 ([kernel.kallsyms])
>         ffffffff917af951 common_lsm_audit+0x2b1 ([kernel.kallsyms])
>         ffffffff91785533 slow_avc_audit+0xb3 ([kernel.kallsyms])
>         ffffffff9178ac54 cred_has_capability.isra.0+0x114 ([kernel.kallsyms])
>         ffffffff917767f0 security_capable+0x70 ([kernel.kallsyms])
>         ffffffff910ff5d2 capable+0x32 ([kernel.kallsyms])
>         ffffffff91508a11 xattr_permission+0xf1 ([kernel.kallsyms])
>         ffffffff91508a95 vfs_getxattr+0x45 ([kernel.kallsyms])
>         ffffffff91509d44 do_getxattr+0x74 ([kernel.kallsyms])
>         ffffffff91509ee1 getxattr+0x91 ([kernel.kallsyms])
>         ffffffff91509fac path_getxattr+0x7c ([kernel.kallsyms])
>         ffffffff9220b262 do_syscall_64+0x82 ([kernel.kallsyms])
>         ffffffff9240012f entry_SYSCALL_64_after_hwframe+0x76
> ([kernel.kallsyms])
>             7fc2296fca3e lgetxattr+0xe (/usr/lib64/libc.so.6)
>             7fc229a2577e getxattr_at_malloc+0x1be
> (/usr/lib64/systemd/libsystemd-shared>
>             7fc229a2646e getxattr_at_bool+0x2e
> (/usr/lib64/systemd/libsystemd-shared-25>
>             7fc2299ab7a4 cg_get_xattr_bool+0x64
> (/usr/lib64/systemd/libsystemd-shared-2>
>             7fc2299ab864 cg_is_delegated+0x24
> (/usr/lib64/systemd/libsystemd-shared-256>
>             55f7745482d9 [unknown] (/usr/lib/systemd/systemd-coredump)

From this, it looks like it's hitting this part of code in systemd:
https://github.com/systemd/systemd/blob/e8908d2fc180f5a98dd37bfbc9c5952de5f18899/src/basic/cgroup-util.c#L2255

Accessing the trusted.* xattrs requires CAP_SYS_ADMIN and it seems that systemd-coredump legitimately needs the ability, so we should grant the capability in the policy, IMO. (Probably in most cases the trusted.delegate xattr will be unset, so it won't make much of a difference, but logically it can happen and we should allow it to work.)

(In reply to Paul DeStefano from comment #47)
> IIRC, at one point, crashes in flatpak were just ignored by abrt.  I
> remember being disappointed at first, but then I decided that was a
> reasonable choice.  Either I'm remembering it wrong, or that rule has
> changed or was broken.
> 
> I think this symptom with coredum(p) only happens with flatpak apps; at
> least that is my experience. However, that doesn't mean the root cause only
> affects flatpak apps.

No matter whether abrt is ignoring crashes in flatpak or not, I think a flatpak app crash should not cause a selinux warning.

(In reply to Paul DeStefano from comment #47)
> IIRC, at one point, crashes in flatpak were just ignored by abrt.  I
> remember being disappointed at first, but then I decided that was a
> reasonable choice.  Either I'm remembering it wrong, or that rule has
> changed or was broken.

Not *yet*: https://discussion.fedoraproject.org/t/gnome-abrt-cant-upload-crash-reports-from-flatpak-apps/66462/6

*** Bug 2342300 has been marked as a duplicate of this bug. ***

*** Bug 2342803 has been marked as a duplicate of this bug. ***

*** Bug 2342842 has been marked as a duplicate of this bug. ***

*** Bug 2343099 has been marked as a duplicate of this bug. ***

*** Bug 2343349 has been marked as a duplicate of this bug. ***

FEDORA-2025-62c612355c (selinux-policy-41.31-1.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-62c612355c

FEDORA-2025-62c612355c has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-62c612355c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-62c612355c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Test update helps in my case. Flatpak application crashes but no SELinux errors appears.

FEDORA-2025-62c612355c (selinux-policy-41.31-1.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.