Codium attempted to access the HEAP on my machine numerous times...

[davior]

Why would would Codium be attempting to access the heap on my machine?

DETAILS:

Could not read file mailto:?subject=SELinux is preventing codium from using the execheap access on a process.&body=SELinux is preventing codium from using the execheap access on a process.%0D%0A%0D%0A%2A%2A%2A%2A%2A  
Plugin allow_execheap %2853.1 confidence%29 suggests   %2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%0D%0A%0D%0A
If you do not think codium should need to map heap memory that is both writable and executable.%0D%0AThen you need to report a bug. This is a potentially dangerous access.%0D%0ADo%0D%0Acontact your security administrator and report this issue.%0D%0A%0D%0A%2A%2A%2A%2A%2A  Plugin catchall_boolean %2842.6 confidence%29 suggests   %2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%0D%0A%0D%0AIf you want to allow selinuxuser to execheap%0D%0A

Then you must tell SELinux about this by enabling the %27selinuxuser_execheap%27 boolean.%0D%0A%0D%0ADo%0D%0Asetsebool -P selinuxuser_execheap 1%0D%0A%0D%0A%2A%2A%2A%2A%2A  Plugin catchall %285.76 confidence%29 suggests   %2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%0D%0A%0D%0A

If you believe that codium should be allowed execheap access on processes labeled unconfined_t by default.%0D%0AThen you should report this as a bug.%0D%0AYou can generate a local policy module to allow this access.%0D%0ADo%0D%0A

allow this access for now by executing%3A%0D%0A%23 

ausearch -c %27codium%27 --raw %7C audit2allow -M my-codium%0D%0A%23 semodule -X 300 -i my-codium.pp%0D%0A%0D%0A

Additional Information%3A%0D%0ASource Context                unconfined_u%3Aunconfined_r%3Aunconfined_t%3As0-%0D%0A                              s0%3Ac0.c1023%0D%0A
Target Context                unconfined_u%3Aunconfined_r%3Aunconfined_t%3As0-%0D%0A                              s0%3Ac0.c1023%0D%0A
Target Objects                Unknown %5B process %5D%0D%0ASource                        codium%0D%0A
Source Path                   codium%0D%0APort                          %3CUnknown%3E%0D%0A
Host                          %28removed%29%0D%0A
Source RPM Packages           %0D%0A
Target RPM Packages           %0D%0ASELinux Policy RPM            selinux-policy-targeted-40.20-1.fc40.noarch%0D%0A
Local Policy RPM              selinux-policy-targeted-40.20-1.fc40.noarch%0D%0ASelinux Enabled               True%0D%0A
Policy Type                   targeted%0D%0A
Enforcing Mode                Enforcing%0D%0AHost Name                     %28removed%29%0D%0APlatform                      
Linux fedora 6.8.11-300.fc40.x86_64 %231 SMP%0D%0A                              PREEMPT_DYNAMIC Mon May 27 14%3A53%3A33 UTC 2024%0D%0A                              x86_64%0D%0A

Alert Count                   84%0D%0AFirst Seen                    2024-06-10 09%3A25%3A45 AEST%0D%0ALast Seen                     2024-06-10 09%3A25%3A46 AEST%0D%0ALocal ID                      84357a74-4079-42e4-9411-e3f2340f1281%0D%0A%0D%0ARaw Audit Messages%0D%0Atype%3DAVC msg%3Daudit%281717975546.208%3A428%29%3A avc%3A  denied  %7B execheap %7D for  pid%3D15493 comm%3D%22codium%22 scontext%3Dunconfined_u%3Aunconfined_r%3Aunconfined_t%3As0-s0%3Ac0.c1023 tcontext%3Dunconfined_u%3Aunconfined_r%3Aunconfined_t%3As0-s0%3Ac0.c1023 tclass%3Dprocess permissive%3D0%0D%0A%0D%0A%0D%0AHash%3A codium%2Cunconfined_t%2Cunconfined_t%2Cprocess%2Cexecheap.

[noonsleeper]

Are vscode or flatpak's vscode doing the same? Are you tried to disable the 3rd party extensions and try to replicate the behaviour? When you create an issue report, it is also a good practice to include distro and flatpak version as minimum.

I search for similar problems from vscode, and I found this https://www.reddit.com/r/Fedora/comments/1ac5ibg/selinux_is_preventing_code_from_using_the/

[noonsleeper]

related to:

• https://lore.kernel.org/selinux/CAFqZXNv0SVT0fkOK6neP9AXbj3nxJ61JAY4+zJzvxqJaeuhbFw@mail.gmail.com/
• https://bugzilla.redhat.com/show_bug.cgi?id=2247299
• https://github.com/ValveSoftware/Proton/issues/7285

[davior]

Are vscode or flatpak's vscode doing the same? Are you tried to disable the 3rd party extensions and try to replicate the behaviour? When you create an issue report, it is also a good practice to include distro and flatpak version as minimum.

I search for similar problems from vscode, and I found this https://www.reddit.com/r/Fedora/comments/1ac5ibg/selinux_is_preventing_code_from_using_the/

I apologize for the lack of details..

I have not tried disabling plugins.. It does look like the issue you listed..

I do not run vscode so I am unsure if it is happening there also.

My distro is: Linux fedora 6.8.11-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Mon May 27 14:53:33 UTC 2024 x86_64 GNU/Linux

With Flatpak 1.15.8

I will attempt to replicate the issue without plugins to see if it makes any difference.

Thanks

[noonsleeper]

I'm running F39 with kernel Linux ranko 6.8.10-200.fc39.x86_64 and don't report any problem.

But I created a vm with F40 kernel Linux fedora 6.8.11-300.fc40.x86_64 and report the same problem that you mention.

Seems a SELinux bug to me

The only workaround until the fix comes to upstream will run as root this:

# Create the exception rule and build a compiled module
ausearch -c codium -m AVC | audit2allow -a -M custom_flatpak_vscodium

# apply the rule
semodule -i custom_flatpak_vscodium.pp

# if you want to remove the rule run this
semodule -r custom_flatpak_vscodium

[daiyam]

Seems a SELinux bug to me

From the reddit, it seems like a bug. VSCode has also the same issue. Also, since those are IDEs, they usually ask for more secure rights/privileges than typical applications, it's where the new SELinux is throwing his hat.

[davior]

Thanks for your help @noonsleeper. I think I'll continue to run without the exception as I would prefer to be informed when this exception occurs (in-case it's for real at some stage) and it doesn't appear to be happening that often.

Thanks again for your help 🙏🏽

[noonsleeper]

I will close this, since is already addressed and is an external bug, If you have another problem don't hesitate and open a new issue =)

[davior]

It's funny that this appears to be happening with wine and MOSTLY Chromium related products.. VS Code uses Chromium, VSCodium uses Chromium. Discord uses Chromium, Valve Software and Proton all use Chromium and Wine, well it's MS. It appears to be a common thread....

I really doubt it is the redhat or fedora base... Unless it's a policy based issue...

More Info defined here ---> https://discussion.fedoraproject.org/t/selinux-execheap-denials/120638/24 AND here ---> https://github.com/ValveSoftware/Proton/issues/7285

[noonsleeper]

Unless it's a policy based issue...

It is a policy issue, indeed

[crimsonfall]

Hi y'all.

As @davior said, I've also experienced this same issue across some other Chromium/Electron based apps; like Zettlr or Discord which sometimes crashes but otherwise opens, although other Chromium apps such as Brave don't have this issue for some reason. I am using Fedora 40 KDE at the moment with the apps mentioned running as Flatpaks, though I doubt the apps being Flatpaks are the issue.

Somebody has also reported this issue to the Red Hat Bugzilla recently (https://bugzilla.redhat.com/show_bug.cgi?id=2294708), however they have marked it as "not a bug". So perhaps it's an issue with Chromium after all?

I've also noticed that I've been having more of these issues ever since I've upgraded my kernel to 6.9.4. Updating to the most recent selinux-policy didn't help either.