Description of problem: I'm uncertain. This occurred within 10 minutes after upgrading to Fedora 40 x86_64, while using Brave in a video call and upon opening Discover to search for a package. SELinux is preventing systemd-coredum from using the 'sys_admin' capabilities. ***** 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 (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.17-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.17-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.8.8-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Apr 27 17:53:31 UTC 2024 x86_64 Alert Count 1 First Seen 2024-05-03 10:48:03 EDT Last Seen 2024-05-03 10:48:03 EDT Local ID f8ea0d56-fc35-4399-a99a-5db981422f6d Raw Audit Messages type=AVC msg=audit(1714747683.23:487): avc: denied { sys_admin } for pid=12139 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 Version-Release number of selected component: selinux-policy-targeted-40.17-1.fc40.noarch Additional info: reporter: libreport-2.17.15 reason: SELinux is preventing systemd-coredum from using the 'sys_admin' capabilities. package: selinux-policy-targeted-40.17-1.fc40.noarch component: selinux-policy hashmarkername: setroubleshoot type: libreport kernel: 6.8.8-300.fc40.x86_64 comment: I'm uncertain. This occurred within 10 minutes after upgrading to Fedora 40 x86_64, while using Brave in a video call and upon opening Discover to search for a package. component: selinux-policy
Created attachment 2031137 [details] File: description
Created attachment 2031138 [details] File: os_info
John, Do you know how to reproduce this issue? Do you have any related system changes? Can you gather logs with full auditing enabled? https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing
Hi, @zpytela, It was on the initial boot after upgrading to Fedora 40 - and the desktop had been up and running for about 6 minutes - seemingly stable. I had opened chrome to run a Gmeet session with my team. After approximately 3 minutes, everything froze for about 60s, the desktop rebooted, and then stuff started working again. At that point I saw this error pop up that something had died and I submitted the bug report here. No idea exactly what happened, but after 6 more reboots and the same workflow, I've had no other reoccurrences. - Jappleii
*** Bug 2279867 has been marked as a duplicate of this bug. ***
*** Bug 2279698 has been marked as a duplicate of this bug. ***
*** Bug 2272027 has been marked as a duplicate of this bug. ***
*** Bug 2264997 has been marked as a duplicate of this bug. ***
*** Bug 2280388 has been marked as a duplicate of this bug. ***
*** Bug 2280756 has been marked as a duplicate of this bug. ***
*** Bug 2282703 has been marked as a duplicate of this bug. ***
*** Bug 2281555 has been marked as a duplicate of this bug. ***
*** Bug 2281412 has been marked as a duplicate of this bug. ***
*** Bug 2281364 has been marked as a duplicate of this bug. ***
*** Bug 2283009 has been marked as a duplicate of this bug. ***
*** Bug 2283023 has been marked as a duplicate of this bug. ***
Hello folks, Despite multiple reports, I am unable to reproduce this denial and gather additional information. Does anyone happen to know how to reproduce it? Or maybe help to gather data with full auditing enabled, stack trace, anything which would help with understanding? https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing
well, it's coredumpd, so you need to make something crash, for a start. here's an extract of my `coredumpctl list` since two days ago: Wed 2024-05-22 11:53:52 PDT 4160 1000 1000 SIGTRAP present /app/discord/Discord 2.3M Wed 2024-05-22 11:59:02 PDT 6723 1000 1000 SIGSEGV present /usr/libexec/dleyna-renderer-service 675.5K Wed 2024-05-22 23:33:53 PDT 34452 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 4.6M Wed 2024-05-22 23:34:01 PDT 38055 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 818.1K Thu 2024-05-23 07:54:35 PDT 42557 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 4.2M Thu 2024-05-23 07:55:21 PDT 42879 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 5.2M Thu 2024-05-23 08:30:13 PDT 48651 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 4.9M Thu 2024-05-23 08:30:24 PDT 48886 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 4.1M Thu 2024-05-23 08:30:39 PDT 49161 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 4.5M Thu 2024-05-23 08:32:01 PDT 49574 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 4.6M Thu 2024-05-23 08:32:11 PDT 42377 1000 1000 SIGSEGV present /usr/bin/evolution 48.2M Thu 2024-05-23 08:32:46 PDT 49960 1000 1000 SIGSEGV present /usr/libexec/dleyna-renderer-service 458.7K Thu 2024-05-23 09:09:16 PDT 53758 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 4.6M Thu 2024-05-23 09:09:29 PDT 49982 1000 1000 SIGSEGV present /usr/bin/evolution 45.5M Thu 2024-05-23 09:14:31 PDT 54459 1000 1000 SIGSEGV present /usr/libexec/dleyna-renderer-service 477.2K Thu 2024-05-23 09:14:43 PDT 54637 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 4.6M Thu 2024-05-23 09:14:51 PDT 54468 1000 1000 SIGSEGV present /usr/bin/evolution 20.6M Thu 2024-05-23 09:28:54 PDT 57558 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 4.3M Thu 2024-05-23 10:00:19 PDT 60503 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 4.8M Thu 2024-05-23 10:11:05 PDT 61995 1000 1000 SIGSEGV present /usr/libexec/webkit2gtk-4.1/WebKitWebProcess 5.0M Thu 2024-05-23 10:11:15 PDT 57332 1000 1000 SIGSEGV present /usr/bin/evolution 43.3M and here's `journalctl -b | grep -i avc | grep coredump_t` over the same timeframe: May 22 11:53:51 xps13a.happyassassin.net audit[4456]: AVC avc: denied { sys_admin } for pid=4456 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 May 22 23:33:42 xps13a.happyassassin.net audit[37973]: AVC avc: denied { sys_admin } for pid=37973 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 May 22 23:33:57 xps13a.happyassassin.net audit[38078]: AVC avc: denied { sys_admin } for pid=38078 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 May 23 07:54:24 xps13a.happyassassin.net audit[42589]: AVC avc: denied { sys_admin } for pid=42589 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 May 23 07:55:11 xps13a.happyassassin.net audit[42911]: AVC avc: denied { sys_admin } for pid=42911 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 May 23 08:30:06 xps13a.happyassassin.net audit[48758]: AVC avc: denied { sys_admin } for pid=48758 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 May 23 08:30:19 xps13a.happyassassin.net audit[48912]: AVC avc: denied { sys_admin } for pid=48912 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 May 23 08:30:33 xps13a.happyassassin.net audit[49191]: AVC avc: denied { sys_admin } for pid=49191 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 May 23 08:31:55 xps13a.happyassassin.net audit[49625]: AVC avc: denied { sys_admin } for pid=49625 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 May 23 09:09:06 xps13a.happyassassin.net audit[53783]: AVC avc: denied { sys_admin } for pid=53783 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 May 23 09:14:37 xps13a.happyassassin.net audit[54733]: AVC avc: denied { sys_admin } for pid=54733 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 May 23 09:28:44 xps13a.happyassassin.net audit[57581]: AVC avc: denied { sys_admin } for pid=57581 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 May 23 10:00:13 xps13a.happyassassin.net audit[60808]: AVC avc: denied { sys_admin } for pid=60808 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 May 23 10:10:59 xps13a.happyassassin.net audit[62021]: AVC avc: denied { sys_admin } for pid=62021 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 so it kinda looks like the denials happen shortly before (most) crashes are recorded by coredumpd. The Evolution and WebKit crashes are quite easy to reproduce for me - just set up Evolution and try to read some email, it seems to be frequently crashing in webkit ATM. See https://gitlab.gnome.org/GNOME/evolution/-/issues/2759 .
*** Bug 2283819 has been marked as a duplicate of this bug. ***
*** Bug 2283381 has been marked as a duplicate of this bug. ***
*** Bug 2283627 has been marked as a duplicate of this bug. ***
*** Bug 2283286 has been marked as a duplicate of this bug. ***
Certainly I made a few dozens of services crash, I can list them by coredumpctl, but I can't see the sys_admin capability request. I need to see some details, at least syscall etc. The sys_admin capability is too powerful so it needs to be well justified.
Log from killing Flatpak OBS with SIGSEGV via htop: ---- type=PROCTITLE msg=audit(29/05/24 03:35:59.724:4816) : proctitle=/usr/lib/systemd/systemd-coredump 1545889 1337 1337 11 1716950159 18446744073709551615 pointy.local type=PATH msg=audit(29/05/24 03:35:59.724:4816) : item=0 name=/sys/fs/cgroup/user.slice/user-1337.slice/user inode=7693 dev=00:1a mode=dir,755 ouid=pointy ogid=pointy 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(29/05/24 03:35:59.724:4816) : cwd=/ type=SYSCALL msg=audit(29/05/24 03:35:59.724:4816) : arch=x86_64 syscall=lgetxattr success=no exit=ENODATA(No data available) a0=0x55fdbf6adf00 a1=0x7f36a950da1b a2=0x55fdbf6b5b50 a3=0x67 items=1 ppid=2 pid=1546112 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(29/05/24 03:35:59.724:4816) : avc: denied { sys_admin } for pid=1546112 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 Log from killing DiscordCanary with "DiscordNative.app.relaunch()" in console: ---- type=PROCTITLE msg=audit(31/05/24 00:52:29.291:5869) : proctitle=/usr/lib/systemd/systemd-coredump 1841637 1337 1337 5 1717113149 18446744073709551615 pointy.local type=PATH msg=audit(31/05/24 00:52:29.291:5869) : item=0 name=/sys/fs/cgroup/user.slice/user-1337.slice/user inode=7693 dev=00:1a mode=dir,755 ouid=pointy ogid=pointy 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(31/05/24 00:52:29.291:5869) : cwd=/ type=SYSCALL msg=audit(31/05/24 00:52:29.291:5869) : arch=x86_64 syscall=lgetxattr success=no exit=ENODATA(No data available) a0=0x5604651ecbf0 a1=0x7f0fd390da56 a2=0x5604651eea20 a3=0x67 items=1 ppid=2 pid=1841640 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(31/05/24 00:52:29.291:5869) : avc: denied { sys_admin } for pid=1841640 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 Hope these help. ~Elliott
*** Bug 2290509 has been marked as a duplicate of this bug. ***
FEDORA-2024-9fae7e7b23 (selinux-policy-40.22-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-9fae7e7b23
FEDORA-2024-9fae7e7b23 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-9fae7e7b23` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-9fae7e7b23 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-9fae7e7b23 (selinux-policy-40.22-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
I got this just today on F41. DNF says "Nothing to do." when I try to upgrade the repository. I'm confused. 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 <redacted> Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-41.28-1.fc41.noarch Local Policy RPM selinux-policy-targeted-41.28-1.fc41.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name <redacted> Platform Linux <redacted> 6.12.9-200.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jan 9 16:05:40 UTC 2025 x86_64 Alert Count 5 First Seen 2025-01-06 21:14:48 PST Last Seen 2025-01-16 17:04:11 PST Local ID <redacted> Raw Audit Messages type=AVC msg=audit(1737075851.260:10272): avc: denied { sys_admin } for pid=4036118 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
Sorry, I meant "when I try to upgrade the *advisory*" not "repository".
That is a bit odd, yeah. This is a six-month old bug report and your selinux-policy is much newer than that. Perhaps it's regressed? Zdenek, WDYT?
There certainly is a problem, let's continue in https://bugzilla.redhat.com/show_bug.cgi?id=2335200