[GH-ISSUE #1414] Firefox Nightly broken due to firejail's seccomp

gitea-mirror commented

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

Owner

Originally created by @RalfJung on GitHub (Jul 29, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1414

Firefox is itself sandboxing the content processes with seccomp. Nesting seccomp does not seem to be possible, so the fact that firejail uses seccomp actually silently breaks Firefox' sandbox and decreases their isolation.
To make things worse, current Firefox nightly breaks badly when used in firejail; it seems the breakage of seccomp is no longer silent. Also see https://bugzilla.mozilla.org/show_bug.cgi?id=1384804 for some more information.

I commented out the "seccomp" filter in the firefox.profile to fix my issues. I think that should be shipped as new default, or else people will experience breakage when using Firefox with firejail.

Originally created by @RalfJung on GitHub (Jul 29, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1414 Firefox is itself sandboxing the content processes with seccomp. Nesting seccomp does not seem to be possible, so the fact that firejail uses seccomp actually silently breaks Firefox' sandbox and *decreases* their isolation. To make things worse, current Firefox nightly breaks badly when used in firejail; it seems the breakage of seccomp is no longer silent. Also see https://bugzilla.mozilla.org/show_bug.cgi?id=1384804 for some more information. I commented out the "seccomp" filter in the firefox.profile to fix my issues. I think that should be shipped as new default, or else people will experience breakage when using Firefox with firejail.

gitea-mirror

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

closed this issue
added the
enhancement
label

gitea-mirror commented

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

Author

Owner

@curiosity-seeker commented on GitHub (Jul 30, 2017):

I cannot confirm this for Nightly 56.0a1 on Fedora 26. It works for me both with /etc/firejail/firefox.profile and with my modified profile where I added some other stuff. In fact, I'm writing this in the firejailed Nightly.

However, this may be different on another distro. Which one are you using?

Having said that, I think that problems with Firejail can be expected once the Firefox sandbox is complete. It is basically the one used in Chromium - and for that one it depends on if your distro supports user namespaces or not, see this post and the discussion thereafter. For example, I can use Google Chrome with the settings mentioned in that post and with a long list of syscalls in seccomp.keep. If you're using a distro that doesn't support user namespaces that won't be possible.

@curiosity-seeker commented on GitHub (Jul 30, 2017): I cannot confirm this for Nightly 56.0a1 on Fedora 26. It works for me both with /etc/firejail/firefox.profile and with my modified profile where I added some other stuff. In fact, I'm writing this in the firejailed Nightly. However, this may be different on another distro. Which one are you using? Having said that, I think that problems with Firejail can be expected once the Firefox sandbox is complete. It is basically the one used in Chromium - and for that one it depends on if your distro supports user namespaces or not, see [this](https://github.com/netblue30/firejail/issues/554#issuecomment-303456703) post and the discussion thereafter. For example, I can use Google Chrome with the settings mentioned in that post and with a [long list of syscalls](https://github.com/netblue30/firejail/issues/554#issuecomment-305469593) in `seccomp.keep`. If you're using a distro that doesn't support user namespaces that won't be possible.

gitea-mirror commented

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

Author

Owner

@RalfJung commented on GitHub (Jul 30, 2017):

I am using Debian teseting. Also, I should have been more clear: Not all websites are broken. One particular website which reliably breaks for me (and which I used for the regression test in the Firefox bugreport I linked) is https://youtube.com.

@RalfJung commented on GitHub (Jul 30, 2017): I am using Debian teseting. Also, I should have been more clear: Not all websites are broken. One particular website which reliably breaks for me (and which I used for the regression test in the Firefox bugreport I linked) is <https://youtube.com>.

gitea-mirror commented

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

Author

Owner

@SkewedZeppelin commented on GitHub (Jul 30, 2017):

I did a bit of testing and I cannot repro this issue. As gcp said in the linked bug report, I agree that Firejail is silently breaking Firefox's sandbox and or Firefox is falsely reporting under about:support, and 'seccomp' will need to be eventually removed as has been done for Chromium-based browsers.

@SkewedZeppelin commented on GitHub (Jul 30, 2017): I did a bit of testing and I cannot repro this issue. As gcp said in the linked bug report, I agree that Firejail is silently breaking Firefox's sandbox and or Firefox is falsely reporting under about:support, and 'seccomp' will need to be eventually removed as has been done for Chromium-based browsers.

gitea-mirror commented

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

Author

Owner

@RalfJung commented on GitHub (Jul 31, 2017):

I did a bit of testing and I cannot repro this issue.

Strange. Maybe it has something to do with drivers (video playback seems involved, with YouTube being a trigger for me). I'm on an Intel card, and I think I got the video acceleration drivers installed.

@RalfJung commented on GitHub (Jul 31, 2017): > I did a bit of testing and I cannot repro this issue. Strange. Maybe it has something to do with drivers (video playback seems involved, with YouTube being a trigger for me). I'm on an Intel card, and I think I got the video acceleration drivers installed.

gitea-mirror commented

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

Author

Owner

@curiosity-seeker commented on GitHub (Jul 31, 2017):

Okay, for whatever reason I ran into problems today, too. Firefox Nightly wouldn't even start. After playing around a while I added this line to the profile:

seccomp.keep access,arch_prctl,bind,brk,capget,capset,chmod,clock_getres,clone,close,connect,dup2,epoll_create1,epoll_ctl,epoll_wait,eventfd2,execve,exit,exit_group,fadvise64,fallocate,fchmod,fchown,fcntl,fstat,fstatfs,fsync,ftruncate,futex,getcwd,getdents,getdents64,getegid,geteuid,getgid,get_mempolicy,getpeername,getpgrp,getpid,getppid,getpriority,getrandom,getresgid,getresuid,getrusage,getsockname,getsockopt,gettid,getuid,inotify_add_watch,inotify_init1,ioctl,kill,lseek,lstat,madvise,memfd_create,mkdir,mmap,mprotect,munmap,nanosleep,open,pipe,pipe2,poll,pread64,prlimit64,ptrace,pwrite64,quotactl,read,readahead,readlink,recvfrom,recvmsg,rename,rmdir,rt_sigaction,rt_sigprocmask,rt_sigreturn,sched_getaffinity,sched_yield,seccomp,sendmmsg,sendmsg,sendto,setpriority,setresgid,setresuid,set_robust_list,setsockopt,set_tid_address,shmat,shmctl,shmdt,shmget,shutdown,sigaltstack,socket,socketpair,splice,stat,statfs,symlink,sysinfo,tgkill,umask,uname,unlink,unshare,wait4,write,writev

This seems to work well on my Fedora 26 system with an Intel GPU. It's possible that your Debian system needs some more. So if you're running into problems I suggest that you execute

journalctl -e | grep syscall

and

firejail --debug-syscalls | grep XXX

where XXX is the syscall number output from journalctl. It might be necessary to repeat those steps several times. Just add those syscalls to above list.

EDIT: Above list is very long, indeed. However, if you compare it with the default list of syscalls blocked by Firejail using comm -12 you'll find that only the two whitelisted syscalls

get_mempolicy
ptrace

are in the default list. All other syscalls in above list are not blocked by Firejail anyhow - but they have to be added to seccomp.keep nonetheless.

@curiosity-seeker commented on GitHub (Jul 31, 2017): Okay, for whatever reason I ran into problems today, too. Firefox Nightly wouldn't even start. After playing around a while I added this line to the profile: ``` seccomp.keep access,arch_prctl,bind,brk,capget,capset,chmod,clock_getres,clone,close,connect,dup2,epoll_create1,epoll_ctl,epoll_wait,eventfd2,execve,exit,exit_group,fadvise64,fallocate,fchmod,fchown,fcntl,fstat,fstatfs,fsync,ftruncate,futex,getcwd,getdents,getdents64,getegid,geteuid,getgid,get_mempolicy,getpeername,getpgrp,getpid,getppid,getpriority,getrandom,getresgid,getresuid,getrusage,getsockname,getsockopt,gettid,getuid,inotify_add_watch,inotify_init1,ioctl,kill,lseek,lstat,madvise,memfd_create,mkdir,mmap,mprotect,munmap,nanosleep,open,pipe,pipe2,poll,pread64,prlimit64,ptrace,pwrite64,quotactl,read,readahead,readlink,recvfrom,recvmsg,rename,rmdir,rt_sigaction,rt_sigprocmask,rt_sigreturn,sched_getaffinity,sched_yield,seccomp,sendmmsg,sendmsg,sendto,setpriority,setresgid,setresuid,set_robust_list,setsockopt,set_tid_address,shmat,shmctl,shmdt,shmget,shutdown,sigaltstack,socket,socketpair,splice,stat,statfs,symlink,sysinfo,tgkill,umask,uname,unlink,unshare,wait4,write,writev ``` This seems to work well on my Fedora 26 system with an Intel GPU. It's possible that your Debian system needs some more. So if you're running into problems I suggest that you execute `journalctl -e | grep syscall` and `firejail --debug-syscalls | grep XXX` where XXX is the syscall number output from journalctl. It might be necessary to repeat those steps several times. Just add those syscalls to above list. EDIT: Above list is very long, indeed. However, if you compare it with the default list of syscalls blocked by Firejail using `comm -12` you'll find that only the two whitelisted syscalls ``` get_mempolicy ptrace ``` are in the default list. All other syscalls in above list are not blocked by Firejail anyhow - but they have to be added to `seccomp.keep` nonetheless.

gitea-mirror commented

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

Author

Owner

@RalfJung commented on GitHub (Jul 31, 2017):

TBH I think it makes more sense to just not have firejail just not restrict syscalls -- these filters seems very fragile. firejail still uses mount namespaces to isolate all of Firefox from my private files, so this is much more secure than "just" the Firefox sandbox.

@RalfJung commented on GitHub (Jul 31, 2017): TBH I think it makes more sense to just not have firejail just not restrict syscalls -- these filters seems very fragile. firejail still uses mount namespaces to isolate all of Firefox from my private files, so this is much more secure than "just" the Firefox sandbox.

gitea-mirror commented

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

Author

Owner

@netblue30 commented on GitHub (Aug 2, 2017):

I've managed to reproduce it, and I removed get_mempolicy from the default seccomp list. It seems to be able to play youtube videos now. Once they release the version now in nightly, we'll have to test again and see if we can bring back get_mempolicy in the seccomp filter.

@netblue30 commented on GitHub (Aug 2, 2017): I've managed to reproduce it, and I removed get_mempolicy from the default seccomp list. It seems to be able to play youtube videos now. Once they release the version now in nightly, we'll have to test again and see if we can bring back get_mempolicy in the seccomp filter.

gitea-mirror commented

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

Author

Owner

@gcp commented on GitHub (Aug 18, 2017):

FWIW I just landed a fix in for this, and Firefox now blocks get_mempolicy too. Should be in tomorrow's Nightly.

@gcp commented on GitHub (Aug 18, 2017): FWIW I just landed a fix in for this, and Firefox now blocks get_mempolicy too. Should be in tomorrow's Nightly.

gitea-mirror commented

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

Author

Owner

@netblue30 commented on GitHub (Aug 18, 2017):

Thanks, I'll keep an eye on it and bring back get_mempolicy.

@netblue30 commented on GitHub (Aug 18, 2017): Thanks, I'll keep an eye on it and bring back get_mempolicy.

gitea-mirror commented

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

Author

Owner

@hlieberman commented on GitHub (Sep 13, 2017):

For what it's worth, this still seems to be broken on Nightly 57.0a1 (2017-09-13) with firejail 0.9.48. @gcp, if the fix was supposed to work on the Moz side independently, something else is wrong.

@hlieberman commented on GitHub (Sep 13, 2017): For what it's worth, this still seems to be broken on Nightly 57.0a1 (2017-09-13) with firejail 0.9.48. @gcp, if the fix was supposed to work on the Moz side independently, something else is wrong.

gitea-mirror commented

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

Author

Owner

@gcp commented on GitHub (Sep 14, 2017):

I'm not sure what "still" means given that this was confirmed fixed a month ago, or what "broken" means.

@gcp commented on GitHub (Sep 14, 2017): I'm not sure what "still" means given that this was confirmed fixed a month ago, or what "broken" means.

gitea-mirror commented

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

Author

Owner

@curiosity-seeker commented on GitHub (Sep 14, 2017):

I don't have any problems with Nightly since @gcp landed that fix. However, I'm using the Firejail git version.
@hlieberman : You're still using 0.9.48 but 0.9.50 is available. Perhaps that one solves your problem.

@curiosity-seeker commented on GitHub (Sep 14, 2017): I don't have any problems with Nightly since @gcp landed that fix. However, I'm using the Firejail git version. @hlieberman : You're still using 0.9.48 but 0.9.50 is available. Perhaps that one solves your problem.

gitea-mirror commented

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

Author

Owner

@hlieberman commented on GitHub (Sep 15, 2017):

Confirmed; problem goes away in 0.9.50. Thanks!

@hlieberman commented on GitHub (Sep 15, 2017): Confirmed; problem goes away in 0.9.50. Thanks!

gitea-mirror commented

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

Author

Owner

@gcp commented on GitHub (Sep 19, 2017):

if the fix was supposed to work on the Moz side independently, something else is wrong.

The fix on our side was backed out, which is why this requires an updated firejail right now:
https://bugzilla.mozilla.org/show_bug.cgi?id=1384804#c25

I will try to reland the fix on Firefox, but the conclusion is that it seems to be impossible to block get_mempolicy because some versions of libnuma require it even if they can read /prof/.../status

@gcp commented on GitHub (Sep 19, 2017): >if the fix was supposed to work on the Moz side independently, something else is wrong. The fix on our side was backed out, which is why this requires an updated firejail right now: https://bugzilla.mozilla.org/show_bug.cgi?id=1384804#c25 I will try to reland the fix on Firefox, but the conclusion is that it seems to be impossible to block get_mempolicy because some versions of libnuma require it even if they can read /prof/.../status

gitea-mirror referenced this issue

2026-05-05 10:08:17 -06:00

[PR #963] [MERGED] Wireshark #3807

Rows
Columns

[GH-ISSUE #1414] Firefox Nightly broken due to firejail's seccomp #963