Firefox 60+ fails to run content processes

[johnp]

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.

[smitsohu]

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?

[johnp]

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]

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.

[SkewedZeppelin]

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

[smitsohu]

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.

[johnp]

@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.

[m0n5t3r]

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)

[smitsohu]

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.

[Vincent43]

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?

[smitsohu]

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

[Vincent43]

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

[smitsohu]

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.

[Vincent43]

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).

[smitsohu]

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.

[Vincent43]

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.

[Fred-Barclay]

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.

[smitsohu]

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.

[Fred-Barclay]

This should hopefully be fixed in upstream now.
seccomp was replaced with the string @smitsohu provided in #1765 (comment)

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.

[pizzadude]

@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?

[Fred-Barclay]

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

[pizzadude]

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