Description of problem: On a system where the SELinux boolean deny_execmem is set to 'on', Firefox 67.0.4 crashes with a segmentation fault when executed. The AVC rather pointedly tells me that I should report this in bugzilla so... here you go! Version-Release number of selected component (if applicable): Firefox 67.0.4 How reproducible: 100%, at least so far Steps to Reproduce: 1. setsebool deny_execmem=1 2. /usr/bin/firefox 3. Actual results: Segmentation fault Expected results: Normal operation of the browser Additional info: The SELinux AVC is: SELinux is preventing firefox from using the execmem access on a process. ***** Plugin catchall_boolean (89.3 confidence) suggests ****************** If you want to deny user domains applications to map a memory region as both executable and writable, this is dangerous and the executable should be reported in bugzilla Then you must tell SELinux about this by enabling the 'deny_execmem' boolean. Do setsebool -P deny_execmem 0 ***** Plugin catchall (11.6 confidence) suggests ************************** If you believe that firefox should be allowed execmem 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 'firefox' --raw | audit2allow -M my-firefox # semodule -X 300 -i my-firefox.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Objects Unknown [ process ] Source firefox Source Path firefox Port <Unknown> Host onyx.variosecure.net Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.3-39.fc30.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name onyx.variosecure.net Platform Linux onyx.variosecure.net 5.1.15-300.fc30.x86_64 #1 SMP Tue Jun 25 14:07:22 UTC 2019 x86_64 x86_64 Alert Count 3 First Seen 2019-07-03 21:08:25 JST Last Seen 2019-07-03 21:10:49 JST Local ID 0e57d8fb-9451-46f3-aef5-e7e18919a5ea Raw Audit Messages type=AVC msg=audit(1562155849.985:630): avc: denied { execmem } for pid=21913 comm="xxx" 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: firefox,unconfined_t,unconfined_t,process,execmem
Here's some scant information from the firefox coredump. If there's a way to get more useful data, just let me know. PID: 28140 (firefox) UID: 1066 (yyy) GID: 1067 (yyy) Signal: 11 (SEGV) Timestamp: Wed 2019-07-03 21:30:12 JST (2min 26s ago) Command Line: /usr/lib64/firefox/firefox Executable: /usr/lib64/firefox/firefox Control Group: /user.slice/user-1000.slice/session-2.scope Unit: session-2.scope Slice: user-1000.slice Session: 2 Owner UID: 1000 (xxx) Boot ID: dc9832fc9ad548c3bc1b8875c3a2e28a Machine ID: b8d71d9e27084a46a0f9ec8d1cac4176 Hostname: zzzz.zzzzzzzzzzz.org Storage: /var/lib/systemd/coredump/core.firefox.1066.dc9832fc9ad548c3bc1b8875c3a2e28a.28140.1562157012000000.lz4 Message: Process 28140 (firefox) of user 1066 dumped core. Stack trace of thread 28140: #0 0x00007f3877947d15 raise (libpthread.so.0) #1 0x00007f3870991513 n/a (libxul.so) #2 0x00007f3877947e80 __restore_rt (libpthread.so.0) #3 0x00007f387006b084 n/a (libxul.so) #4 0x00007f38721cf254 n/a (libxul.so) #5 0x00007f38721bfbcb n/a (libxul.so) #6 0x0000557ade60c784 n/a (firefox) #7 0x0000557ade608463 n/a (firefox) #8 0x00007f3877433f33 __libc_start_main (libc.so.6) #9 0x0000557ade604c2e _start (firefox) Stack trace of thread 28175: #0 0x00007f3877505fad syscall (libc.so.6) #1 0x00007f38721d419b epoll_wait (libxul.so) #2 0x00007f38721d40bb n/a (libxul.so) #3 0x00007f38721d3f19 n/a (libxul.so) #4 0x00007f38721d3623 n/a (libxul.so) #5 0x00007f38721d3559 n/a (libxul.so) #6 0x00007f38721d246e n/a (libxul.so) #7 0x00007f38721d236b n/a (libxul.so) #8 0x00007f387793d5a2 start_thread (libpthread.so.0) #9 0x00007f387750b303 __clone (libc.so.6)
Just updating to say that, unfortunately, the problem still exists in Firefox 68.0.
Yes, and won't be fixed. It's due to JS engine design. Feel free to escalate to mozilla. I did patches for it years ago and those weren't accepted.
> I did patches for it years ago and those weren't accepted. Can you post the links, in case anyone wanted to follow up on that?
(In reply to Pavel Raiskup from comment #4) > > I did patches for it years ago and those weren't accepted. > > Can you post the links, in case anyone wanted to follow up on that? https://bugzilla.mozilla.org/show_bug.cgi?id=506693