[GH-ISSUE #2506] firefox-common.profile: seccomp instead of seccomp.drop ?

gitea-mirror commented

2026-05-05 08:16:59 -06:00

Owner

Originally created by @curiosity-seeker on GitHub (Mar 3, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2506

I recently ran firejail --audit firefox which reported (among other things):

---------------- Firejail Audit: the GOOD, the BAD and the UGLY ----------------
INFO: starting /usr/lib/firejail/faudit.
GOOD: process 31 is running in a PID namespace.
INFO: container/sandbox firejail.

GOOD: seccomp BPF enabled.
checking syscalls: mount... umount2... ptrace... swapon... swapoff... init_module... delete_module... chroot... 
UGLY: chroot syscall permitted.
pivot_root... iopl... ioperm...

So I added

ignore seccomp.drop
seccomp

to my individual firefox profile in ~/.config/firejail and repeated the test: Above UGLY output didn't appear anymore, and so far I haven't noticed any problems with that changed setting.

Note that I tested it on Manjaro KDE. I don't know if the chroot syscall might still be necessary on other distros or for other Firefox-based browsers. But it's possible that something has changed since FF v. 60. So perhaps other users can confirm (or not) if it's working for them.

As a sidenote: the syscall groups used in that profile are nowhere documented AFAIK. They are only listed in man firejail but the syscalls which belong to each group are not enumerated. This prevents proper usage of those groups. Perhaps they are identical to the ones documented for systemd but no one can really tell ;-)

Originally created by @curiosity-seeker on GitHub (Mar 3, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2506 I recently ran `firejail --audit firefox` which reported (among other things): ``` ---------------- Firejail Audit: the GOOD, the BAD and the UGLY ---------------- INFO: starting /usr/lib/firejail/faudit. GOOD: process 31 is running in a PID namespace. INFO: container/sandbox firejail. GOOD: seccomp BPF enabled. checking syscalls: mount... umount2... ptrace... swapon... swapoff... init_module... delete_module... chroot... UGLY: chroot syscall permitted. pivot_root... iopl... ioperm... ``` So I added ``` ignore seccomp.drop seccomp ``` to my individual firefox profile in ~/.config/firejail and repeated the test: Above UGLY output didn't appear anymore, and so far I haven't noticed any problems with that changed setting. Note that I tested it on Manjaro KDE. I don't know if the chroot syscall might still be necessary on other distros or for other Firefox-based browsers. But it's possible that something has changed since FF v. 60. So perhaps other users can confirm (or not) if it's working for them. As a sidenote: the syscall groups used in that profile are nowhere documented AFAIK. They are only listed in man firejail but the syscalls which belong to each group are not enumerated. This prevents proper usage of those groups. Perhaps they are identical to the ones documented for systemd but no one can really tell ;-)

gitea-mirror closed this issue

2026-05-05 08:16:59 -06:00

gitea-mirror commented

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

Author

Owner

@curiosity-seeker commented on GitHub (Mar 3, 2019):

Regarding syscall groups: As mentioned in man systemd.exec

systemd-analyze syscall-filter

lists the actual syscalls in each group. A similar command would be very useful for the Firejail syscall groups particularly if those lists are too big for man firejail.

@curiosity-seeker commented on GitHub (Mar 3, 2019): Regarding syscall groups: As mentioned in `man systemd.exec` `systemd-analyze syscall-filter` lists the actual syscalls in each group. A similar command would be very useful for the Firejail syscall groups particularly if those lists are too big for `man firejail`.

gitea-mirror commented

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

Author

Owner

@Vincent43 commented on GitHub (Mar 3, 2019):

Could you also try to test with kernel.unprivileged_userns_clone=1 sysctl to mimic ubuntu environment?

In other news noroot breaks GTK_USE_PORTAL=1 usage.

@Vincent43 commented on GitHub (Mar 3, 2019): Could you also try to test with `kernel.unprivileged_userns_clone=1` sysctl to mimic ubuntu environment? In other news `noroot` breaks `GTK_USE_PORTAL=1` usage.

gitea-mirror commented

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

Author

Owner

@curiosity-seeker commented on GitHub (Mar 4, 2019):

Ah - yes! With sudo sysctl kernel.unprivileged_userns_clone=1 I can't load any website.

@curiosity-seeker commented on GitHub (Mar 4, 2019): Ah - yes! With `sudo sysctl kernel.unprivileged_userns_clone=1` I can't load any website.

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Mar 4, 2019):

Auditing firefox profile also shows the below for me:
...
UGLY: I can access files in /home/glitsj16/.mozilla directory. Use "firejail --blacklist=/home/glitsj16/.mozilla" to block it.
...

Does this represent a false-positive in the audit code? Surely firefox needs access to that path, and firefox.profile does a mkdir/whitelist on it.

@ghost commented on GitHub (Mar 4, 2019): Auditing firefox profile also shows the below for me: ... UGLY: I can access files in /home/glitsj16/.mozilla directory. Use "firejail --blacklist=/home/glitsj16/.mozilla" to block it. ... Does this represent a false-positive in the audit code? Surely firefox needs access to that path, and firefox.profile does a mkdir/whitelist on it.

gitea-mirror commented

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

Author

Owner

@Vincent43 commented on GitHub (Mar 5, 2019):

Audit has set of hardcoded dirs to check regardless of audited profile so sometimes it doesn't make sense.

@Vincent43 commented on GitHub (Mar 5, 2019): Audit has set of [hardcoded dirs](https://github.com/netblue30/firejail/blob/0d2f252230283ffcd97795b65e5f29ceaf9bf824/src/faudit/files.c#L64) to check regardless of audited profile so sometimes it doesn't make sense.

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Mar 5, 2019):

@Vincent43 Thanks for pointing that out.
@curiosity-seeker Confirming your workaround works fine on Arch Linux, alas it breaks firefox on Ubuntu 16.04 LTS. The latter seemingly still needs the chroot syscall. Instead of loosing the gains from your observations by doing nothing to the profile, perhaps adding a small note can be helpful.

@ghost commented on GitHub (Mar 5, 2019): @Vincent43 Thanks for pointing that out. @curiosity-seeker Confirming your workaround works fine on Arch Linux, alas it breaks firefox on Ubuntu 16.04 LTS. The latter seemingly still needs the chroot syscall. Instead of loosing the gains from your observations by doing nothing to the profile, perhaps adding a small note can be helpful.

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Mar 8, 2019):

Added relevant info from this thread to firefox-common.profile in https://github.com/netblue30/firejail/pull/2541.

@ghost commented on GitHub (Mar 8, 2019): Added relevant info from this thread to firefox-common.profile in https://github.com/netblue30/firejail/pull/2541.

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Mar 18, 2019):

@curiosity-seeker Closing this. Feel free to re-open if you feel this needs something extra. Thanks for pointing this out here.

@ghost commented on GitHub (Mar 18, 2019): @curiosity-seeker Closing this. Feel free to re-open if you feel this needs something extra. Thanks for pointing this out here.

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Jun 16, 2019):

@curiosity-seeker Using the full seccomp filter worked just fine here on my Arch Linux machines ever since you reported this here. Sadly it recently stopped working. I'm not exactly sure if it's caused by kernel or Firefox changes. But around the FF67 update I noticed it. Would you be so kind to confirm/deny if it is still working for you? Just in case it doesn't we should remove or edit the comment in firefox-common.profile.

@ghost commented on GitHub (Jun 16, 2019): @curiosity-seeker Using the full seccomp filter worked just fine here on my Arch Linux machines ever since you reported this here. Sadly it `recently stopped working`. I'm not exactly sure if it's caused by kernel or Firefox changes. But around the FF67 update I noticed it. Would you be so kind to confirm/deny if it is still working for you? Just in case it doesn't we should remove or edit the [comment](https://github.com/netblue30/firejail/blob/master/etc/firefox-common.profile#L51) in firefox-common.profile.

gitea-mirror commented

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

Author

Owner

@curiosity-seeker commented on GitHub (Jun 17, 2019):

@glitsj16 : seccomp still works for me on Manjaro with the Firefox Developer Edition 68.0b8. I didn't have visible problems with FF 67, either.

However, I had one very weird problem with v. 67: I had been running Pi-Hole on a Raspberry Pi and now AdGuardHome which handles all DNS requests. The disturbing thing was that I saw network requests in its query log which should have been blocked by uBlock Origin (and were, indeed, displayed as blocked in the uBO logger). This only happens with v. 67, not with 68.0b8 and not with Chromium or Vivaldi. I cannot imagine that this is somehow related to special syscalls - but I should check it again with the seccomp.drop line instead to make this sure.

@curiosity-seeker commented on GitHub (Jun 17, 2019): @glitsj16 : `seccomp` still works for me on Manjaro with the Firefox Developer Edition 68.0b8. I didn't have visible problems with FF 67, either. However, I had one very weird problem with v. 67: I had been running Pi-Hole on a Raspberry Pi and now AdGuardHome which handles all DNS requests. The disturbing thing was that I saw network requests in its query log which should have been blocked by uBlock Origin (and were, indeed, displayed as blocked in the uBO logger). This only happens with v. 67, not with 68.0b8 and not with Chromium or Vivaldi. I cannot imagine that this is somehow related to special syscalls - but I should check it again with the `seccomp.drop` line instead to make this sure.

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Jun 17, 2019):

@curiosity-seeker Thanks for responding. That's good news, even though it means I'll have to do some more digging to try and find the reason why it stopped working for me. Too bad FF67 wasn't exactly the smoothest of upgrades for you, I had a few mishaps myself (related to the now fixed custom home page bug). Anyway, thanks again for confirming this still works. At least we can leave the comment as is. I'll try the Developer Edition shortly, I do like the extra confidence this use of full seccomp filtering brings. Cheers!

@ghost commented on GitHub (Jun 17, 2019): @curiosity-seeker Thanks for responding. That's `good news`, even though it means I'll have to do some more digging to try and find the reason why it stopped working for me. Too bad FF67 wasn't exactly the smoothest of upgrades for you, I had a few mishaps myself (related to the now fixed custom home page bug). Anyway, thanks again for confirming this still works. At least we can leave the comment as is. I'll try the Developer Edition shortly, I do like the extra confidence this use of full seccomp filtering brings. Cheers!

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Jan 28, 2020):

Sadly it recently stopped working. I'm not exactly sure if it's caused by kernel or Firefox changes.

I never got around to dig any deeper. Assuming kernel changes were to blame I learned to live with it and accepted whatever seccomp filtering was done in firefox-common.profile. Today, on an unrelated matter, I came across Mozilla documentation related to the Firefox native sandbox. Apparently on Linux the browser uses a default security sandbox content level of 4, which (amongst other measures) uses a chroot jail. I guess that accounts for the OP's audit observations above, which still shows the same 'UGLY: chroot syscall permitted', as the profile currently uses 'seccomp !chroot' and 'ignore seccomp.drop' won't do anything any longer.

If you prefer to use firejail's full seccomp filter, all it takes is lowering this to level 3 in the Firefox preferences. One way to achieve this is by opening the about:config page and changing security.sandbox.content.level accordingly. Then you can add the below to your firefox-common.local to enforce firejail seccomp:

ignore seccomp !chroot
seccomp

The 'Sandbox' section on the Firefox about:support page can be used to double-check the changed level.

DISCLAIMER: whether or not it is wise to mess with the native Firefox sandbox is another matter. I spent only one full day using Firefox with firejail like this. So far nothing seems broken, but I haven't gotten a grip on the involved implications yet, if ever.

@ghost commented on GitHub (Jan 28, 2020): > Sadly it recently stopped working. I'm not exactly sure if it's caused by kernel or Firefox changes. I never got around to dig any deeper. Assuming _kernel_ changes were to blame I learned to live with it and accepted whatever seccomp filtering was done in firefox-common.profile. Today, on an unrelated matter, I came across [Mozilla documentation related to the Firefox native sandbox](https://wiki.mozilla.org/Security/Sandbox). Apparently on Linux the browser uses a default security sandbox content level of **4**, which (amongst other measures) uses a [chroot jail](https://wiki.mozilla.org/Security/Sandbox#Content_Levels). I guess that accounts for the OP's audit observations above, which still shows the same 'UGLY: chroot syscall permitted', as the profile currently uses 'seccomp !chroot' and 'ignore seccomp.drop' won't do anything any longer. If you prefer to use firejail's **full** seccomp filter, all it takes is lowering this to level **3** in the Firefox preferences. One way to achieve this is by opening the about:config page and changing `security.sandbox.content.level` accordingly. Then you can add the below to your firefox-common.local to enforce firejail seccomp: ``` ignore seccomp !chroot seccomp ``` The 'Sandbox' section on the Firefox about:support page can be used to double-check the changed level. **DISCLAIMER**: whether or not it is wise to mess with the native Firefox sandbox is another matter. I spent only one full day using Firefox with firejail like this. So far nothing seems broken, but I haven't gotten a grip on the involved implications yet, if ever.

Rows
Columns

[GH-ISSUE #2506] firefox-common.profile: seccomp instead of seccomp.drop ? #1632