[GH-ISSUE #1765] Firefox 60+ fails to run content processes

gitea-mirror commented

2026-05-05 07:38:10 -06:00

Owner

Originally created by @johnp on GitHub (Feb 7, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1765

Firefox Nightly doesn't seem to be able to start child processes / no tabs loading websites (except about:-stuff, which AFAIK runs in the parent process), crashing them instead:

https://crash-stats.mozilla.com/report/index/288d3c2b-c0be-4a85-af97-b294f0180207

I suspect bug 1401062 to be the issue, but don't know how to debug further.

firejail latest master / 0.9.53 on Fedora 27, works with --noprofile.

Originally created by @johnp on GitHub (Feb 7, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1765 Firefox Nightly doesn't seem to be able to start child processes / no tabs loading websites (except `about:`-stuff, which AFAIK runs in the parent process), crashing them instead: https://crash-stats.mozilla.com/report/index/288d3c2b-c0be-4a85-af97-b294f0180207 I suspect [bug 1401062](https://bugzilla.mozilla.org/show_bug.cgi?id=1401062) to be the issue, but don't know how to debug further. firejail latest master / 0.9.53 on Fedora 27, works with `--noprofile`.

gitea-mirror

2026-05-05 07:38:10 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 07:38:13 -06:00

Author

Owner

@smitsohu commented on GitHub (Feb 7, 2018):

Thanks for your report. Could you please check briefly if it works when you replace seccomp in /etc/firejail/firefox.profile with the long seccomp.drop line from qutebrowser profile?

@smitsohu commented on GitHub (Feb 7, 2018): Thanks for your report. Could you please check briefly if it works when you replace `seccomp` in /etc/firejail/firefox.profile with the long `seccomp.drop` line from [qutebrowser profile](https://raw.githubusercontent.com/netblue30/firejail/ca3964fed3f141e75bf396defaec3dca543ce49f/etc/qutebrowser.profile)?

gitea-mirror commented

2026-05-05 07:38:14 -06:00

Author

Owner

@johnp commented on GitHub (Feb 7, 2018):

No, doesn't work, but I just saw that a ~~fresh firefox profile works fine~~. I'll check my preferences to see what's triggering the issue...

@johnp commented on GitHub (Feb 7, 2018): No, doesn't work, but I just saw that a ~~fresh firefox profile works fine~~. I'll check my preferences to see what's triggering the issue...

gitea-mirror commented

2026-05-05 07:38:17 -06:00

Author

Owner

@johnp commented on GitHub (Feb 7, 2018):

I verified via mozregression that bug 140162 is the issue. (pushlog)

Ok, now I tried again several times and a fresh profile doesn't work either, but --safe-mode does.

@johnp commented on GitHub (Feb 7, 2018): I verified via mozregression that bug 140162 is the issue. ([pushlog](https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cba9a29be139a663869a2c26557fd527a6981407&tochange=bd7ff5744eb29e105b7b3c37cb5f46164fa11ef4)) Ok, now I tried again several times and a fresh profile doesn't work either, but `--safe-mode` does.

gitea-mirror commented

2026-05-05 07:38:17 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Feb 7, 2018):

We'll probably eventually need to remove seccomp and add caps.keep sys_chroot,sys_admin like chromium.profile as mentioned in #1414.

@SkewedZeppelin commented on GitHub (Feb 7, 2018): We'll probably eventually need to remove` seccomp` and add `caps.keep sys_chroot,sys_admin` like chromium.profile as mentioned in #1414.

gitea-mirror commented

2026-05-05 07:38:19 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 17, 2018):

It seems that three options are causing problems: noroot, seccomp and apparmor. They work just fine in some distributions (Arch, Debian) and are breaking Firefox in others (Fedora, Ubuntu), depending on how distributions handle unprivileged user namespaces.

@johnp Can you please comment out these lines in your Firefox profile and give it a try? Instead of disabling seccomp altogether, you can also replace it with this long line:

seccomp.drop @clock,@cpu-emulation,@debug,@module,@obsolete,@raw-io,@reboot,@resources,@swap,acct,add_key,bpf,fanotify_init,io_cancel,io_destroy,io_getevents,io_setup,io_submit,ioprio_set,kcmp,keyctl,mount,name_to_handle_at,nfsservctl,ni_syscall,open_by_handle_at,personality,pivot_root,process_vm_readv,ptrace,remap_file_pages,request_key,setdomainname,sethostname,syslog,umount,umount2,userfaultfd,vhangup,vmsplice

If you want to double-check: Adding chroot to the seccomp.drop line should crash Firefox again.

@smitsohu commented on GitHub (Mar 17, 2018): It seems that three options are causing problems: `noroot`, `seccomp` and `apparmor`. They work just fine in some distributions (Arch, Debian) and are breaking Firefox in others (Fedora, Ubuntu), depending on how distributions handle unprivileged user namespaces. @johnp Can you please comment out these lines in your Firefox profile and give it a try? Instead of disabling `seccomp` altogether, you can also replace it with this long line: ``` seccomp.drop @clock,@cpu-emulation,@debug,@module,@obsolete,@raw-io,@reboot,@resources,@swap,acct,add_key,bpf,fanotify_init,io_cancel,io_destroy,io_getevents,io_setup,io_submit,ioprio_set,kcmp,keyctl,mount,name_to_handle_at,nfsservctl,ni_syscall,open_by_handle_at,personality,pivot_root,process_vm_readv,ptrace,remap_file_pages,request_key,setdomainname,sethostname,syslog,umount,umount2,userfaultfd,vhangup,vmsplice ``` If you want to double-check: Adding `chroot` to the `seccomp.drop` line should crash Firefox again.

gitea-mirror commented

2026-05-05 07:38:20 -06:00

Author

Owner

@johnp commented on GitHub (Mar 18, 2018):

@smitsohu Yes, works with noroot, seccomp and apparmor commented out and with the seccomp.drop line together with noroot and apparmor commented out. Adding chroot makes Firefox unusable again.

@johnp commented on GitHub (Mar 18, 2018): @smitsohu Yes, works with `noroot`, `seccomp` and `apparmor` commented out and with the `seccomp.drop` line together with `noroot` and `apparmor` commented out. Adding `chroot` makes Firefox unusable again.

gitea-mirror commented

2026-05-05 07:38:21 -06:00

Author

Owner

@m0n5t3r commented on GitHub (Mar 23, 2018):

on Ubuntu 16.04 (and firejail 0.9.52 from ppa:deki/firejail) I had to drop pivot-root from the seccomp line above (original issue: I was seeing blank windows, closing them didn't end the firefox program, but it would crash later in libmozsandbox.so - I assume it does some sort of chroot-ing on its own and needs that capability).

it works for me with noroot in there, btw. (and there is no apparmor line in my version of firejail)

@m0n5t3r commented on GitHub (Mar 23, 2018): on Ubuntu 16.04 (and firejail 0.9.52 from ppa:deki/firejail) I had to drop pivot-root from the seccomp line above (original issue: I was seeing blank windows, closing them didn't end the firefox program, but it would crash later in libmozsandbox.so - I assume it does some sort of chroot-ing on its own and needs that capability). it works for me with noroot in there, btw. (and there is no apparmor line in my version of firejail)

gitea-mirror commented

2026-05-05 07:38:22 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 23, 2018):

Thanks @m0n5t3r for the data point.

With regard to the Apparmor policy: Firefox crashes when it can't write to /proc/[pid]/uid_map, gid_map or setgroups.

@smitsohu commented on GitHub (Mar 23, 2018): Thanks @m0n5t3r for the data point. With regard to the Apparmor policy: [Firefox crashes](https://searchfox.org/mozilla-central/source/security/sandbox/linux/launch/SandboxLaunch.cpp#473) when it can't write to /proc/[pid]/uid_map, gid_map or setgroups.

gitea-mirror commented

2026-05-05 07:38:22 -06:00

Author

Owner

@Vincent43 commented on GitHub (Mar 23, 2018):

With regard to the Apparmor policy: Firefox crashes when it can't write to /proc/[pid]/uid_map, gid_map or setgroups.

That never happened to me. Is this new nightly thing?

@Vincent43 commented on GitHub (Mar 23, 2018): > With regard to the Apparmor policy: Firefox crashes when it can't write to /proc/[pid]/uid_map, gid_map or setgroups. That never happened to me. Is this new nightly thing?

gitea-mirror commented

2026-05-05 07:38:24 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 23, 2018):

@Vincent43 Yep, it's only Nightly (for now).

@smitsohu commented on GitHub (Mar 23, 2018): @Vincent43 Yep, it's only Nightly (for now).

gitea-mirror commented

2026-05-05 07:38:24 -06:00

Author

Owner

@Vincent43 commented on GitHub (Mar 23, 2018):

Ok, we can fix it with adding owner /proc/[0-9]*/{uid_map,gid_map,setgroups} w, to firejail apparmor profile.

@Vincent43 commented on GitHub (Mar 23, 2018): Ok, we can fix it with adding `owner /proc/[0-9]*/{uid_map,gid_map,setgroups} w,` to firejail apparmor profile.

gitea-mirror commented

2026-05-05 07:38:25 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 29, 2018):

Someone an idea why noroot is breaking it?

~~It seems the user mapping goes a wrong way~~ with noroot, /proc/[firefoxPID]/* files are not owned by the user but by nobody inside the sandbox. EDIT: That might also be the reason why shell none is causing problems in #1847. Actually both options seem to break Firefox only jointly.

Another question is if this should be fixed in nightly/dev profiles, or directly in firefox-common.inc.

@smitsohu commented on GitHub (Mar 29, 2018): Someone an idea why `noroot` is breaking it? ~~It seems the user mapping goes a wrong way~~ with `noroot`, /proc/[firefoxPID]/* files are not owned by the user but by nobody inside the sandbox. EDIT: That might also be the reason why `shell none` is causing problems in #1847. Actually both options seem to break Firefox only _jointly_. Another question is if this should be fixed in nightly/dev profiles, or directly in firefox-common.inc.

gitea-mirror commented

2026-05-05 07:38:27 -06:00

Author

Owner

@Vincent43 commented on GitHub (Apr 5, 2018):

I think we should remove noroot,seccomp,shell from firefox-common.inc otherwise it will be broken again after firefox 60 release (firejail releases are't that often).

@Vincent43 commented on GitHub (Apr 5, 2018): I think we should remove `noroot,seccomp,shell` from `firefox-common.inc` otherwise it will be broken again after firefox 60 release (firejail releases are't that often).

gitea-mirror commented

2026-05-05 07:38:27 -06:00

Author

Owner

@smitsohu commented on GitHub (Apr 5, 2018):

It should be sufficient to either disable noroot or shell none, I guess we have a choice here. Also since most of seccomp works well, how about a seccomp.drop line in firefox-common?

Btw, I still see problems only with chroot and have not been able to replicate the issue with pivot_root yet. Maybe I'm missing a condition?

EDITED: @Vincent43 but yes, I would agree to fix directly in firefox-common. palemon and basilisk could then get their own profiles without redirection.

@smitsohu commented on GitHub (Apr 5, 2018): It should be sufficient to either disable `noroot` or `shell none`, I guess we have a choice here. Also since most of `seccomp` works well, how about a `seccomp.drop` line in firefox-common? Btw, I still see problems only with chroot and have not been able to replicate the issue with pivot_root yet. Maybe I'm missing a condition? EDITED: @Vincent43 but yes, I would agree to fix directly in firefox-common. palemon and basilisk could then get their own profiles without redirection.

gitea-mirror commented

2026-05-05 07:38:28 -06:00

Author

Owner

@Vincent43 commented on GitHub (Apr 5, 2018):

I don't think seccomp is worth to keep when firefox rolls its own seccomp filter (and this is probably reason why it's breaking). We can trust upstream knowing which calls should be allowed. We don't use it in chromium profile already.

In my understanding norootbehavior differs on various distros (on some doesn't cause problems) so maybe disabling shell is better option.

@Vincent43 commented on GitHub (Apr 5, 2018): I don't think `seccomp` is worth to keep when firefox rolls its own seccomp filter (and this is probably reason why it's breaking). We can trust upstream knowing which calls should be allowed. We don't use it in chromium profile already. In my understanding `noroot`behavior differs on various distros (on some doesn't cause problems) so maybe disabling `shell` is better option.

gitea-mirror commented

2026-05-05 07:38:29 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Apr 5, 2018):

I'd prefer to have at least seccomp.drop. We may have to get rid of it entirely some day for Firefox, but for now I think we ought to keep seccomp around in some form.

We should probably drop shell none instead of noroot too. We can always control exactly which shells are present, and what can be called through them, with private-bin even without shell none.

@Fred-Barclay commented on GitHub (Apr 5, 2018): I'd prefer to have at least `seccomp.drop`. We may have to get rid of it entirely some day for Firefox, but for now I think we ought to keep seccomp around in some form. We should probably drop `shell none` instead of `noroot` too. We can always control exactly which shells are present, and what can be called through them, with `private-bin` even without `shell none`.

gitea-mirror commented

2026-05-05 07:38:30 -06:00

Author

Owner

@smitsohu commented on GitHub (Apr 5, 2018):

seccomp.drop should still be useful since the Firefox parent process runs without any sandbox AFAIK, similar to the situation with Chromium.

Mozilla has spoken out against a SUID sandbox because it breaks support for downloading and running Firefox as a regular user, without installation, something Chromium has never attempted to support. As a consequence, seccomp.drop should do the job also in the foreseeable future.

+1 for disabling shell none.

@smitsohu commented on GitHub (Apr 5, 2018): `seccomp.drop` should still be useful since the Firefox parent process runs without any sandbox AFAIK, similar to the situation with Chromium. Mozilla has [spoken out](https://wiki.mozilla.org/Security/Sandbox/Specifics#Linux) against a SUID sandbox because it breaks support for downloading and running Firefox as a regular user, without installation, something Chromium has never attempted to support. As a consequence, `seccomp.drop` should do the job also in the foreseeable future. +1 for disabling `shell none`.

gitea-mirror commented

2026-05-05 07:38:31 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Apr 7, 2018):

This should hopefully be fixed in upstream now.
seccomp was replaced with the string @smitsohu provided in https://github.com/netblue30/firejail/issues/1765#issuecomment-373925382

After a brief discussion, pivot_root was left in as neither @smitsohu nor I were able to reproduce any issues with it (I tested firefox nightly and beta on Mint 18.2).

shell none was also commented out.

@Fred-Barclay commented on GitHub (Apr 7, 2018): This should hopefully be fixed in upstream now. `seccomp` was replaced with the string @smitsohu provided in https://github.com/netblue30/firejail/issues/1765#issuecomment-373925382 After a brief [discussion](https://github.com/netblue30/firejail/pull/1865#issuecomment-379408569), `pivot_root` was left in as neither @smitsohu nor I were able to reproduce any issues with it (I tested firefox nightly and beta on Mint 18.2). `shell none` was also commented out.

gitea-mirror commented

2026-05-05 07:38:32 -06:00

Author

Owner

@pizzadude commented on GitHub (Apr 9, 2018):

@Fred-Barclay it isn't fixed for me

I had to fix it manually, by commenting out:
nogroups

and possibly:
noroot
apparmor
(but not sure if those need to be commented out)

and disable-mnt because i have downloads folder in /media but that's unrelated

and this is on debian sid with firefox nightly and firejail latest git

Edit:
After testing again, it turns out I need to disable a few more settings, but I don't know which ones, so it looks like this:

https://pastebin.com/raw/GQx3BVyA
(there's more to the seccomp line, but it's truncated because i copy/pasted from nano)

which ones are the most important security wise?

@pizzadude commented on GitHub (Apr 9, 2018): @Fred-Barclay it isn't fixed for me I had to fix it manually, by commenting out: nogroups and possibly: noroot apparmor (but not sure if those need to be commented out) and disable-mnt because i have downloads folder in /media but that's unrelated and this is on debian sid with firefox nightly and firejail latest git Edit: After testing again, it turns out I need to disable a few more settings, but I don't know which ones, so it looks like this: https://pastebin.com/raw/GQx3BVyA (there's more to the seccomp line, but it's truncated because i copy/pasted from nano) which ones are the most important security wise?

gitea-mirror commented

2026-05-05 07:38:33 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Apr 9, 2018):

@pizzadude we had to change a few other settings for apparmor. Can you build from the latests source and test again?
Thanks!
Fred

@Fred-Barclay commented on GitHub (Apr 9, 2018): @pizzadude we had to change a few other settings for apparmor. Can you build from the latests source and test again? Thanks! Fred

gitea-mirror commented

2026-05-05 07:38:34 -06:00

Author

Owner

@pizzadude commented on GitHub (Apr 10, 2018):

@Fred-Barclay
It works fine when I comment tracelog out. It seems tracelog is the culprit. I'm not sure why. (not a programmer)

@pizzadude commented on GitHub (Apr 10, 2018): @Fred-Barclay It works fine when I comment tracelog out. It seems tracelog is the culprit. I'm not sure why. (not a programmer)

gitea-mirror referenced this issue

2026-05-05 08:58:15 -06:00

[GH-ISSUE #3627] X11 security #2279

Rows
Columns

[GH-ISSUE #1765] Firefox 60+ fails to run content processes #1197