SELinux Execheap Denials

I have been noticing within the past couple days denials from SELinux when using the official Discord binary (from the tar.gz archive) on discord.com as well as the official Visual Studio Code (VS Code) rpm (which I installed through adding Microsoft’s official yum repo). I am using the KDE spin of Fedora 40 workstation.

This might be related to a discussion created yesterday, but I am not sure as I don’t use Chrome and don’t seem to be having any issues with mount points (I haven’t manually added any). Also, from my DNF logs, it seems like I upgraded to selinux-policy-40.22-1.fc40 on June 11, while I’ve only noticed issues starting yesterday.

Result of cat /var/log/dnf.* | grep selinux-policy-40.22-1.fc40
2024-06-11T23:40:36-0500 INFO Downloading: http://southfront.mm.fcix.net/fedora/linux/updates/40/Everything/x86_64/Packages/s/selinux-policy-40.22-1.fc40.noarch.rpm
2024-06-11T23:44:05-0500 DEBUG Upgraded: selinux-policy-40.22-1.fc40.noarch
2024-06-11T23:44:05-0500 DDEBUG /var/cache/dnf/updates-02a32a5ce99e20ab/packages/selinux-policy-40.22-1.fc40.noarch.rpm removed
2024-06-11T23:42:02-0500 SUBDEBUG Upgrade: selinux-policy-40.22-1.fc40.noarch

Yesterday I was programming using VS Code and noticed in the bottom right corner of my screen, an SELinux denial warning was rapidly appearing and disappearing.

I haven’t changed anything about my system recently besides installing updates using dnf upgrade and updating discord manually by getting the new tar.gz archive.

To reproduce this issue with VS Code:

  1. Open VS Code
  2. See if you get a denial notification.
  3. If you don’t get a denial notification, restart VS Code multiple times until one appears.

As for Discord, I have tried restarting it multiple times to see if I can get the issue to reappear, but I haven’t been able to. It seems like it’s random chance if it happens when I restart my computer (as I have Discord to start automatically).

Here is a relevant entry from the system journal for Discord:

Jun 19 11:33:20 ben-desktop audit[2879]: AVC avc:  denied  { execheap } for  pid=2879 comm="Discord" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0

And here’s one for VS Code:

Jun 19 12:35:55 ben-desktop setroubleshoot[5638]: SELinux is preventing code from using the execheap access on a process. For complete SELinux messages run: sealert -l 28faa476-865b-473f-9d01-9da82ba04c3e

And here’s the full output of sealert -l 28faa476-865b-473f-9d01-9da82ba04c3e

full output
SELinux is preventing code from using the execheap access on a process.

*****  Plugin allow_execheap (53.1 confidence) suggests   ********************

If you do not think code should need to map heap memory that is both writable and executable.
Then you need to report a bug. This is a potentially dangerous access.
Do
contact your security administrator and report this issue.

*****  Plugin catchall_boolean (42.6 confidence) suggests   ******************

If you want to allow selinuxuser to execheap
Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean.

Do
setsebool -P selinuxuser_execheap 1

*****  Plugin catchall (5.76 confidence) suggests   **************************

If you believe that code should be allowed execheap access on processes labeled unconfined_t 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 'code' --raw | audit2allow -M my-code
# semodule -X 300 -i my-code.pp


Additional Information:
Source Context                unconfined_u:unconfined_r:unconfined_t:s0-
                              s0:c0.c1023
Target Context                unconfined_u:unconfined_r:unconfined_t:s0-
                              s0:c0.c1023
Target Objects                Unknown [ process ]
Source                        code
Source Path                   code
Port                          <Unknown>
Host                          ben-desktop
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-40.22-1.fc40.noarch
Local Policy RPM              selinux-policy-targeted-40.22-1.fc40.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     ben-desktop
Platform                      Linux ben-desktop 6.9.4-200.fc40.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Wed Jun 12 13:33:34 UTC 2024
                              x86_64
Alert Count                   10040
First Seen                    2024-06-18 22:28:36 CDT
Last Seen                     2024-06-19 12:35:46 CDT
Local ID                      28faa476-865b-473f-9d01-9da82ba04c3e

Raw Audit Messages
type=AVC msg=audit(1718818546.151:1236): avc:  denied  { execheap } for  pid=11269 comm="code" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0


Hash: code,unconfined_t,unconfined_t,process,execheap

When this issue occurs (at least with VS Code), it seems to spam notifications and the system journal and it takes some seconds for my computer to catch up to stop displaying them after closing the application.

I have researched how SELinux works and understand the main idea of it. But, I haven’t needed to interact with it before. I don’t understand what execheap is. It seems to have something to do with mapping memory that is readable and writable. But I’m not sure what that means and why it’s an issue.

I would appreciate any help with this. Is there a workaround I can use in the meantime (like allowing VS Code’s process temporarily) so I can still do my work? I didn’t want to do something dangerous that could end up making my system insecure without some outside input.

4 Likes

I guess this is related to a known issue [1] introduced by selinux-policy-40.22-1.fc40 that we already tackle in a bug ticket and thus also related to [2], which is another topic here.

So far, I would like to simplify things and just ask for some actions and then some outputs:

  1. get the output of sudo journalctl | grep execheap (I want to know when this occurred the first time and if it is related to your update to selinux-policy-40.22-1.fc40, just like you, I expect the issues have started after this update, but we want to be sure)
  2. then, create a dedicated boot: boot your machine (or reboot), login, do a little what you usually do when the denials are provoked - I guess using discord? - and then shutdown. (Feel free to also note what exactly you did at the very moment of the denial(s))
  3. Now boot again, and immediately at the next boot, you get the output of sudo journalctl --boot=-1 -g avc:..denied
  4. Now also get the output of sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Then provide the mentioned outputs here.

If applicable, I will add it as complementary information to the bug report. Otherwise, we might create a new one, just in case it is something different.

Do you always update with dnf? Then you might also provide output cat /var/log/dnf.* | grep 2024-06-1 | grep Upgraded (feel free to cut it to the day and the day before the day on which issues you experienced started → we want to know what was installed in between the time when you did what you did without issues and when you did it the first time with the issues)

[1] 2292191 – 40.22-1.fc40 breaks cryptsetup action on startup: related denial logged during boot since update to 40.22-1 -> related device no longer mounted on boot
[2] Repeated security messages from SELinux

2 Likes

The logs are quite large (the result of sudo journalctl | grep execheap is 16.7MiB). Would you like me to provide excerpts from them? Alternatively I can upload them to an online drive service I use if you want them in entirety.

Then skip the sudo journalctl | grep execheap step for now. I can formulate a more restrictive command if I get the outputs of the other steps.

Okay. Something that may be important to note is that I have clicked “Delete” in the SELinux Troubleshooter for alerts recently (but not since starting this discussion). I’m not sure if that affects the logs on disk. Here is the output from the commands.

  1. Skipping for now

  2. Dedicated boot:
    I restarted a couple times and proceeded to log in until Discord crashed on auto-start. Along with Discord, some other applications are set to auto start: Filen and Telegram. I exited the GUIs of Telegram and Filen (but they still run with an icon in the system tray). The denials appeared within KDE’s desktop environment as notifications. And then I shut down my computer and ran the command you provided.

  3. sudo journalctl --boot=-1 -g avc:..denied command
    Unfortunately, I had to remove a lot of it so the forum would accept it.

Result
Jun 19 13:31:36 ben-desktop audit[3536]: AVC avc:  denied  { execheap } for  pid=3536 comm="ThreadPoolForeg" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0

Removed some of the log entries in between here.

Jun 19 13:31:36 ben-desktop audit[3536]: AVC avc:  denied  { execheap } for  pid=3536 comm="ThreadPoolForeg" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
Jun 19 13:31:36 ben-desktop audit[3536]: AVC avc:  denied  { execheap } for  pid=3536 comm="ThreadPoolForeg" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
Jun 19 13:31:36 ben-desktop audit[3536]: AVC avc:  denied  { execheap } for  pid=3536 comm="ThreadPoolForeg" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
Jun 19 13:31:36 ben-desktop audit[3536]: AVC avc:  denied  { execheap } for  pid=3536 comm="Discord" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
Jun 19 13:31:36 ben-desktop audit[3536]: AVC avc:  denied  { execheap } for  pid=3536 comm="Discord" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
Jun 19 13:31:36 ben-desktop audit[3536]: AVC avc:  denied  { execheap } for  pid=3536 comm="Discord" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
Jun 19 13:31:36 ben-desktop audit[3536]: AVC avc:  denied  { execheap } for  pid=3536 comm="Discord" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
  1. sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today command

Unfortunately, this one is just over 7000 lines long (a lot of it repeats), here’s some unique lines. I can upload the full log if needed.

type=AVC msg=audit(06/19/2024 10:41:52.133:196) : avc:  denied  { execheap } for  pid=4382 comm=code scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 
----
type=AVC msg=audit(06/19/2024 10:41:54.293:842) : avc:  denied  { execheap } for  pid=4600 comm=code scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 
----
type=AVC msg=audit(06/19/2024 13:31:36.061:306) : avc:  denied  { execheap } for  pid=3536 comm=ThreadPoolForeg scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 
----
type=AVC msg=audit(06/19/2024 13:31:36.065:311) : avc:  denied  { execheap } for  pid=3536 comm=Discord scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 
  1. I mostly update with DNF, but sometimes I use Discover. I don’t think I’ve updated with Discover in the past week though. Although, I did install Blender with Discover maybe 5 days ago.

Here’s the output of cat /var/log/dnf.* | grep 2024-06-1 | grep Upgraded starting June 17th (day before I noticed issues) until now.

Result
2024-06-17T23:17:34-0500 SUBDEBUG Upgraded: code-1.90.0-1717531925.el8.x86_64
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: brave-browser-1.66.118-1.x86_64
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: mesa-vulkan-drivers-24.0.9-1.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: nss-3.100.0-1.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: nss-softokn-3.100.0-1.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: mesa-libEGL-24.0.8-1.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: alsa-lib-1.2.11-2.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: nss-tools-3.100.0-1.fc40.x86_64
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: python3-libxml2-2.12.7-1.fc40.x86_64
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: perf-6.8.11-300.fc40.x86_64
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: nss-3.100.0-1.fc40.x86_64
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: libxslt-1.1.39-3.fc40.x86_64
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: alsa-utils-1.2.11-1.fc40.x86_64
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: libxml2-2.12.7-1.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: mesa-libGL-24.0.8-1.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: mesa-libgbm-24.0.8-1.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: mesa-libglapi-24.0.8-1.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: mesa-dri-drivers-24.0.8-1.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: libnsl-2.39-13.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: nss-util-3.100.0-1.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: nspr-4.35.0-23.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: nss-softokn-freebl-3.100.0-1.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: zlib-ng-compat-2.1.6-2.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: glibc-devel-2.39-13.fc40.x86_64
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: glibc-2.39-13.fc40.i686
2024-06-17T23:17:36-0500 SUBDEBUG Upgraded: libxml2-devel-2.12.7-1.fc40.x86_64
2024-06-17T23:17:42-0500 SUBDEBUG Upgraded: containers-common-extra-5:0.59.1-1.fc40.noarch
2024-06-17T23:17:44-0500 SUBDEBUG Upgraded: zlib-ng-compat-devel-2.1.6-2.fc40.x86_64
2024-06-17T23:17:44-0500 SUBDEBUG Upgraded: glibc-gconv-extra-2.39-13.fc40.i686
2024-06-17T23:17:44-0500 SUBDEBUG Upgraded: glibc-headers-x86-2.39-13.fc40.noarch
2024-06-17T23:17:44-0500 SUBDEBUG Upgraded: alsa-ucm-1.2.11-2.fc40.noarch
2024-06-17T23:17:46-0500 SUBDEBUG Upgraded: linux-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:46-0500 SUBDEBUG Upgraded: amd-gpu-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:46-0500 SUBDEBUG Upgraded: amd-ucode-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:46-0500 SUBDEBUG Upgraded: atheros-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:46-0500 SUBDEBUG Upgraded: brcmfmac-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:46-0500 SUBDEBUG Upgraded: cirrus-audio-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:46-0500 SUBDEBUG Upgraded: intel-audio-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:46-0500 SUBDEBUG Upgraded: intel-gpu-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:46-0500 SUBDEBUG Upgraded: mt7xxx-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:46-0500 SUBDEBUG Upgraded: nvidia-gpu-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: nxpwireless-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: realtek-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: tiwilink-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: python3-boto3-1.34.99-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: libertas-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: iwlwifi-mvm-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: iwlwifi-dvm-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: iwlegacy-firmware-20240513-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: linux-firmware-whence-20240513-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: python3-botocore-1.34.99-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: containers-common-5:0.59.1-1.fc40.noarch
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: kernel-headers-6.8.3-300.fc40.x86_64
2024-06-17T23:17:47-0500 SUBDEBUG Upgraded: mesa-filesystem-24.0.8-1.fc40.i686
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: kernel-devel-matched-6.8.11-300.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: distribution-gpg-keys-1.102-1.fc40.noarch
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mesa-vulkan-drivers-24.0.9-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: netavark-1.10.3-3.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: nss-softokn-3.100.0-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mesa-va-drivers-freeworld-24.0.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mesa-libxatracker-24.0.9-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mesa-libEGL-24.0.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: libxml2-2.12.7-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: aardvark-dns-1.10.0-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: alsa-lib-1.2.11-2.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: vim-enhanced-2:9.1.393-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mesa-libGL-24.0.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mesa-libgbm-24.0.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mesa-libglapi-24.0.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mesa-dri-drivers-24.0.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: vim-minimal-2:9.1.393-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: rubberband-3.3.0-3.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: libnsl-2.39-13.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: geos-3.12.1-3.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: nss-softokn-freebl-3.100.0-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: nss-sysinit-3.100.0-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: nss-util-3.100.0-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: nspr-4.35.0-23.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: libdav1d-1.4.0-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: paps-0.8.0-8.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: upower-1.90.2-4.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: libevdev-1.13.1-4.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mariadb-gssapi-server-3:10.11.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mariadb-backup-3:10.11.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mariadb-cracklib-password-check-3:10.11.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mariadb-server-3:10.11.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mariadb-3:10.11.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mariadb-server-utils-3:10.11.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: zlib-ng-compat-2.1.6-2.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: vlc-plugins-freeworld-3.0.20-3.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: gstreamer1-plugins-ugly-1:1.22.12-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: gstreamer1-plugins-bad-freeworld-1:1.22.12-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: libseccomp-2.5.3-8.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: vim-common-2:9.1.393-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mariadb-errmsg-3:10.11.8-1.fc40.noarch
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mariadb-common-3:10.11.8-1.fc40.noarch
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: vim-data-2:9.1.393-1.fc40.noarch
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: vim-filesystem-2:9.1.393-1.fc40.noarch
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: mesa-filesystem-24.0.8-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: xxd-2:9.1.393-1.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: upower-libs-1.90.2-4.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: glibc-all-langpacks-2.39-13.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: glibc-gconv-extra-2.39-13.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: glibc-common-2.39-13.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: glibc-langpack-en-2.39-13.fc40.x86_64
2024-06-17T23:17:48-0500 SUBDEBUG Upgraded: glibc-2.39-13.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: ghostscript-10.02.1-8.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: fwupd-1.9.20-1.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: python3-langtable-0.0.66-1.fc40.noarch
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: passt-0^20240510.g7288448-1.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: annobin-plugin-gcc-12.51-1.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: annobin-docs-12.51-1.fc40.noarch
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: passt-selinux-0^20240510.g7288448-1.fc40.noarch
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: langtable-0.0.66-1.fc40.noarch
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: fwupd-plugin-uefi-capsule-data-1.9.20-1.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: ghostscript-tools-fonts-10.02.1-8.fc40.noarch
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: ghostscript-tools-printing-10.02.1-8.fc40.noarch
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: container-selinux-2:2.231.0-1.fc40.noarch
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: bash-color-prompt-0.4.1-1.fc40.noarch
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: libvpl-1:2.10.2-1.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: fwupd-plugin-flashrom-1.9.20-1.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: fwupd-plugin-modem-manager-1.9.20-1.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: libgs-10.02.1-8.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: pcaudiolib-1.1-14.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: mtools-4.0.43-4.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: highway-1.1.0-1.fc40.x86_64
2024-06-18T23:12:09-0500 SUBDEBUG Upgraded: editorconfig-libs-0.12.7-1.fc40.x86_64
2024-06-19T10:40:00-0500 SUBDEBUG Upgraded: cryptsetup-2.7.2-1.fc40.x86_64
2024-06-19T10:40:00-0500 SUBDEBUG Upgraded: python3-rpmautospec-0.6.3-1.fc40.noarch
2024-06-19T10:40:00-0500 SUBDEBUG Upgraded: webkit2gtk4.1-2.44.1-2.fc40.x86_64
2024-06-19T10:40:00-0500 SUBDEBUG Upgraded: javascriptcoregtk4.1-2.44.1-2.fc40.x86_64
2024-06-19T10:40:00-0500 SUBDEBUG Upgraded: cryptsetup-libs-2.7.2-1.fc40.x86_64
2024-06-19T10:40:00-0500 SUBDEBUG Upgraded: podman-5:5.1.0-1.fc40.x86_64
2024-06-19T10:40:00-0500 SUBDEBUG Upgraded: intel-mediasdk-23.2.2-4.fc40.x86_64

Put it into a code box: mark it and then click the button </> which is above the text field (its right of the bold, italic buttons). Or use a paste bin.

You included -ts today , right? If so, you have some serious amount of denials.

However, again, put it either in a code box or use a paste bin.

Be aware that discord is not supported, and it is generally not suggested to install software that way. So we cannot put much efforts in discord.

So far, I hope that the next update of selinux-policy will solve your issues in general too.

How did you install this?

If it is not a package somewhere from our repos, we cannot make a dedicated case as well, but only hope that the current ticket will solve this one as well.

It is possible that both your VS Code and Discord issues will be solved with the next policy update, which is ready hopefully soon. But it is also possible that they break with some practices if they have been installed from outside our repos, and are more or less intentionally blocked by our newest policies. In any case, a ticket about non-supported software will be closed immediately.

VS Code is based on Electron which is based on Chromium, correct?
Maybe it is the same issue as Repeated security messages from SELinux

Not yet sure, that’s why I wanted to check a consistent ausearch & denial journal. But so far I see no comm=systemd-fstab-g denial. Nevertheless, it could still have the same origin.

EDIT: In at least one case, systemd-fstab-g and execheap denials occurred together. So it might be related. But doesn’t change the below for now:

I will skim through when the author provides it, to check if there is some indication if it is related or not. But so far, I guess we will have to wait for the next update of selinux-policy and hope for it.

We cannot add a ticket for unsupported third party software (unlike VS Code is something from our repo? But I guess not?).


@ben-g keep in mind about the above commands, that --boot=-1 always is the boot before the one you are currently running…

When you prepare the output of journalctl and ausearch that I asked for in my last post (with code box or pastebin), you might use instead:

journalctl -g avc:..denied --since "2024-06-18 00:01:00"
and
sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today (or replace today with yesterday if applicable at the time you do it)

Sure, but imho if some component of Fedora prevent a bunch of third party software to work (i.e. Chrome or any flatpak software coming from flathub), well, I think that it actually is a Fedora issue. :slight_smile:

1 Like

Well, the question is if selinux-policy doesn’t work as intended or if third party software doesn’t do what it is intended to do. Sometimes SELinux also mitigates behavior that doesn’t follow best practices / secure practices (or worse).

SELinux denials can be indeed intended :wink:

For now, I would stick with what is in the report. The case of Chrome is contained anyway, as it might provide noteworthy indication for the assignee.

However, when everything on Fedora works, but something unsupported not, it is the question if the policy for everybody should be blurred to get third party software to work.

But you brought up something else that is indeed relevant: flatpak. Flatpak is officially supported, and the question is then of course if the issue is some third party software, or flatpak. Flatpak should work and shall result in a ticket if it doesn’t work. (I indeed forgot the possibility that VS code could be a flatpak?)

But I see it critical with external binaries from third parties, especially proprietary. Here we have in the past limited ourselves to nvidia. Not sure if the team would consider more than that.

Let’s see what the logs of the user indicate. We need more info in either case. Not yet sure what we are up against in this one.

1 Like

Unfortunately, the overall post text was too large. I originally tried putting it into a code box inside a “hide details” box. It didn’t work. So, here’s the paste of sudo journalctl --boot=-1 -g avc:..denied

Yes, here’s the paste for sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today. It’s spamming the logs. A lot of it is for VS Code.

I installed VS Code by following the instructions on the Visual Studio website (see the section titled “RHEL, Fedora, and CentOS based distributions.” It is not from the Fedora repos.

This is okay. I can’t install everything from official Fedora repos as not every application I want is available there. But, I still want to find a way to work around it if that’s the case so that I can use this software. I use a smaller programming language (Elixir) that has the most support with Visual Studio Code as far as editing features go. And I’d rather use the official version of VS Code.

This is a good point. I forgot it uses Chromium. I took a look at that discussion before, but was unsure if it was the same issue so I made this discussion.

You have good chances that the next selinuc-policy update will solve your problems. But obviously, both packages are not supported, and the way they were installed either.

ThreadPoolForeg seems to be linked to chromium by the way.

However, it doesn’t look like SELinux was considered in the packages. I guess in an confined environment (where SELinux enforces policies also within the user account), they would break intentionally. Anyway, let’s hope the next update works well.

You might follow the bug ticket 2292191 – 40.22-1.fc40 breaks cryptsetup action on startup: related denial logged during boot since update to 40.22-1 -> related device no longer mounted on boot (it is the one that considers the issue that hopefully is also the origin of your problems) and Fedora Updates System

The latter is the link to selinux-policy within our update system. Once the new policy enters it, you will find it there in testing. If you want, you can then test it (it will contain a link to install it early for testing). Once it is pushed to stable in bodhi, it will end up in your normal daily updates.

Okay. For the meantime I have ran sudo setsebool -P selinuxuser_execheap 1 which appears to be a bad idea. But, I’ll check back later on the policy and try running sudo setsebool -P selinuxuser_execheap 0 then.

Thank you for the help!

1 Like

We have a new policy. It is currently in testing, but several people already tested it and since it is just a policy correction, you might already try it if you want. You can install it already at this time with the following command:
sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-2bc43119f3

Before testing, please restore selinuxuser_execheap to its original state.

Feel free to add Karma in bodhi if it works for you:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-2bc43119f3

Despite it being very likely to be linked to indirectly to 2283187, we cannot link your error explicitly to any bug report. So just add karma +1 if it works and do not do a thumbs up to any of the mentioned bugs (or give -1 if it doesn’t solve the issue and then link at the best to the issue here in ask.fedora)

Unfortunately, the new update does not solve the issue in the case I can reproduce. I already reported that. But feel free to keep us updated how it works for you. That might be relevant information for the maintainer to finally solve the issue.

Hello
I had the same problem on fedora 40 with kernel 6.9.4, and no problem with kernel 6.8.11. I have just done the update which installs kernel 6.9.5 and the problem seems partially resolved. Otherwise, terminating the selinux troubleshooter process allows you to get around the problem.

1 Like

Interesting. This is the first case that a 6.9.5 update has solved the issue. Are you sure that you have not installed the new selinux-policy along with 6.9.5 ? We have had several unintended denials, and the recent selinux-policy solved most of them. The two packages were pushed to stable in the same week. What exact denials have you had?

If you are sure that selinux-policy-40.23-1.fc40 was not updated roughly before your issue was solved, it would be nice to see some of your previous denial logs to see which of the issues you had. Some are similar, but not equal.

Maybe other users can verify if updating to 6.9.5 had an impact, but please test the updates to 6.9.5 and selinux-policy-40.23-1.fc40 independently and with rebooting after updating and before testing. We would need to set this (for those this works out) in context to the very denials you experience.

This does not solve the problem. It just disables the means that tell you about it.

I am using kernel 6.9.5 and the issue is not fixed in my case.

Done.

This unfortunately didn’t fix the issue for me. Here’s what I did:

  1. ran sudo setsebool -P selinuxuser_execheap 0
  2. ran VS Code and got denials.
  3. ran sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-2bc43119f3
  4. opened VS Code and still got denials.
  5. restarted computer
  6. opened VS Code and still got denials.

The details of one of the denials I’m currently experiencing is below.

Output of sealert -l d1eddc50-133c-432f-a57f-cc681ba78d35
SELinux is preventing code from using the execheap access on a process.

*****  Plugin allow_execheap (53.1 confidence) suggests   ********************

If you do not think code should need to map heap memory that is both writable and executable.
Then you need to report a bug. This is a potentially dangerous access.
Do
contact your security administrator and report this issue.

*****  Plugin catchall_boolean (42.6 confidence) suggests   ******************

If you want to allow selinuxuser to execheap
Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean.

Do
setsebool -P selinuxuser_execheap 1

*****  Plugin catchall (5.76 confidence) suggests   **************************

If you believe that code should be allowed execheap access on processes labeled unconfined_t 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 'code' --raw | audit2allow -M my-code
# semodule -X 300 -i my-code.pp


Additional Information:
Source Context                unconfined_u:unconfined_r:unconfined_t:s0-
                              s0:c0.c1023
Target Context                unconfined_u:unconfined_r:unconfined_t:s0-
                              s0:c0.c1023
Target Objects                Unknown [ process ]
Source                        code
Source Path                   code
Port                          <Unknown>
Host                          ben-desktop
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-40.23-1.fc40.noarch
Local Policy RPM              selinux-policy-targeted-40.23-1.fc40.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     ben-desktop
Platform                      Linux ben-desktop 6.9.5-200.fc40.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Sun Jun 16 15:47:09 UTC 2024
                              x86_64
Alert Count                   1489
First Seen                    2024-06-24 13:30:31 CDT
Last Seen                     2024-06-24 13:52:55 CDT
Local ID                      d1eddc50-133c-432f-a57f-cc681ba78d35

Raw Audit Messages
type=AVC msg=audit(1719255175.193:365): avc:  denied  { execheap } for  pid=4498 comm="code" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0


Hash: code,unconfined_t,unconfined_t,process,execheap
1 Like

After upgrading to the latest KDE 6.1, I’ve encountered a similar issue with Microsoft Edge. The problem occurs intermittently, appearing on some system startups but not others.

1 Like

Afaik, it uses Chromium as backend. So this is likely to be the same issue.

If you want, you can add some reference to the bugzilla BZ#2292191 (reference to here and to my comment #10 in the ticket in which I already elaborate another topic which among others contains that denial with Chrome) that we have several cases where chromium-based tools cause execheap denials and ask Zdenek if he wants a separated bug report for that or not. It is two issues from the perspective of the symptoms, but I cannot say if they have the same origin. If Zdenek prefers it, you can then open a new bug report

1 Like