Bug 2294839

Summary: Intermittent SELinux execheap denial breaks chromium
Product: [Fedora] Fedora Reporter: Chris Adams <linux>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 40CC: dwalsh, jmontleo, lvrabec, mmalik, nixuser, omosnacek, pkoncity, spotrh, suraj.ghimire7, than, vmojzis, yaneti, zpytela
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-07-18 07:55:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Chris Adams 2024-07-01 00:35:21 UTC
I am working on packaging a perl module for Chrome/Chromium remote control (https://bugzilla.redhat.com/show_bug.cgi?id=2254934) but am having problems that appear to be with Chromium itself. Also, after recent updates, I tend to have trouble starting Chromium (especially after a clean boot), getting SIGILL and the same SELinux denial. Usually stopping and starting it a few times gets it to work (but that's not possible for trying to run "make test" in mock while building an RPM).

The SELinux denial:

type=AVC msg=audit(1719792964.349:227): avc:  denied  { execheap } for  pid=82449 comm="chromium-browse" 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

I tried a few releases:

  chromium-123.0.6312.86-1.fc40.x86_64: works okay
  chromium-124.0.6367.201-1.fc40.x86_64: works okay
  chromium-125.0.6422.141-1.fc40.x86_64: doesn't work (intermittently)
  chromium-126.0.6478.126-1.fc40.x86_64: doesn't work (intermittently)

I'm testing by running one of the perl module tests in a while loop with some debugging turned on. On 123/124, that'll run for a while with no problem, but 125/126 usually only get a couple of good runs before failing. This runs with a fresh empty profile directory each time (so no profile/add-on issues). Since it's for remote control, the test runs headless (so should be no GPU related issues).

If I set SELinux to permissive mode, Chromium runs fine.

When it fails, I also see:

[0630/193132.030188:ERROR:v8_initializer.cc(809)] V8 process OOM (Failed to reserve virtual memory for CodeRange).


Reproducible: Sometimes

Comment 1 Than Ngo 2024-07-18 07:27:04 UTC
It looks like issue in selinux-policy component.

Comment 2 Zdenek Pytela 2024-07-18 07:55:16 UTC

*** This bug has been marked as a duplicate of bug 2254434 ***