[GH-ISSUE #2944] Firejail breaks Brave browser default sandboxing

gitea-mirror commented

2026-05-05 08:30:23 -06:00

Owner

Originally created by @corecontingency on GitHub (Sep 6, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2944

Running brave with firejail has this error:

gzip: /proc/config.gz: Permission denied
User namespaces are not detected as enabled on your system, Brave will run with the sandbox disabled

Brave opens fine, and runs fine, but the sandbox does not work. Image is below.

It seems like brave checks if the kernel has user namespaces enabled by checking /proc/config.gz. Unfortunately, this file cannot be read from the firejail sandbox, so brave assumes user namespaces are disabled (even when they are actually enabled), so it runs with the --no-sandbox flag.

I believe this issue can be fixed if /proc/config.gz is made readable. Unfortunately, even if using a completely blank profile, this file still cannot be read. I have tried passing

noblacklist /proc/config.gz
read-only /proc/config.gz
whitelist /proc/config.gz

but the first two do nothing, and the last says it is an invalid whitelist, and firejail won't run.

How do I make this file accessible from the sandbox?

Originally created by @corecontingency on GitHub (Sep 6, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2944 Running brave with firejail has this error: gzip: /proc/config.gz: Permission denied User namespaces are not detected as enabled on your system, Brave will run with the sandbox disabled Brave opens fine, and runs fine, but the sandbox does not work. Image is below. ![brave_no_sandbox_a](https://user-images.githubusercontent.com/54042889/64463847-60521f80-d0ba-11e9-8372-c5be600fd008.png) It seems like [brave checks](https://github.com/brave/brave-browser/issues/3420) if the kernel has user namespaces enabled by checking `/proc/config.gz`. Unfortunately, this file cannot be read from the firejail sandbox, so brave assumes user namespaces are disabled (even when they are actually enabled), so it runs with the `--no-sandbox` flag. I believe this issue can be fixed if `/proc/config.gz` is made readable. Unfortunately, even if using a completely blank profile, this file still cannot be read. I have tried passing noblacklist /proc/config.gz read-only /proc/config.gz whitelist /proc/config.gz but the first two do nothing, and the last says it is an invalid whitelist, and firejail won't run. How do I make this file accessible from the sandbox?

gitea-mirror

2026-05-05 08:30:23 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 08:30:26 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 7, 2019):

Unfortunately, even if using a completely blank profile

A blank profile (aka --noprofile) can't help here because the blacklist is hardcoded:
2e64e781bb/src/firejail/fs.c (L636)

@rusty-snake commented on GitHub (Sep 7, 2019): > Unfortunately, even if using a completely blank profile A blank profile (aka `--noprofile`) can't help here because the blacklist is hardcoded: https://github.com/netblue30/firejail/blob/2e64e781bb351448edb6e6f31f7c9085ca580382/src/firejail/fs.c#L636

gitea-mirror commented

2026-05-05 08:30:27 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 14, 2019):

@corecontingency
still an issue?

@rusty-snake commented on GitHub (Dec 14, 2019): @corecontingency still an issue?

gitea-mirror commented

2026-05-05 08:30:28 -06:00

Author

Owner

@corecontingency commented on GitHub (Dec 16, 2019):

Yes. Just replicated this exact same bug in a Manjaro VM, using the firejail-git and brave-bin packages from the AUR.

I think that this might be fixed if Brave was able to read /proc/config.gz from the sandbox, but I don't know how hard removing the hardcoded blacklist would be. What is the reasoning behind blacklisting /proc/config.gz? I understand it contains information about the configuration options when the kernel was compiled. Could allowing a program to read this file lead to a sandbox escape, or is it just a case of "better safe than sorry"?

I am not sure how much effort should be put into this, considering chromium has a sandbox already, and the issues that firejail is having with electron based apps.

@corecontingency commented on GitHub (Dec 16, 2019): Yes. Just replicated this exact same bug in a Manjaro VM, using the firejail-git and brave-bin packages from the AUR. I think that this might be fixed if Brave was able to read `/proc/config.gz` from the sandbox, but I don't know how hard removing the hardcoded blacklist would be. What is the reasoning behind blacklisting `/proc/config.gz`? I understand it contains information about the configuration options when the kernel was compiled. Could allowing a program to read this file lead to a sandbox escape, or is it just a case of "better safe than sorry"? I am not sure how much effort should be put into this, considering chromium has a sandbox already, and the issues that firejail is having with electron based apps.

gitea-mirror commented

2026-05-05 08:30:29 -06:00

Author

Owner

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

@corecontingency I've made a tentative patch that you can download and integrate into the firejail-git PKGBUILD you mentioned earlier. The patch enables using --noblacklist /proc/config.gz on the command line / noblacklist /proc/config.gz in a brave.local file.

BEWARE: although I personally don't see much issues in making /proc/config.gz accessable that way, it's just a dirty workaround for now. Would be nice of you could test it and report back though. We'll see what more experienced collaborators think of patching firejail this way later on.

@ghost commented on GitHub (Dec 16, 2019): @corecontingency I've made a [tentative patch](https://gist.github.com/glitsj16/80efb9a399187d3df6ec92aa34572c89) that you can download and integrate into the firejail-git PKGBUILD you mentioned earlier. The patch enables using `--noblacklist /proc/config.gz` on the command line / `noblacklist /proc/config.gz` in a brave.local file. **BEWARE**: although I personally don't see much issues in making /proc/config.gz accessable that way, it's just a dirty workaround for now. Would be nice of you could test it and report back though. We'll see what more experienced collaborators think of patching firejail this way later on.

gitea-mirror commented

2026-05-05 08:30:30 -06:00

Author

Owner

@corecontingency commented on GitHub (Dec 16, 2019):

It works! After compiling with the patch, I added noblacklist /proc/config.gz to the profile. Shown below is what chrome://sandbox shows in brave running under firejail:

Now for the discussion about how much danger this adds to the sandbox...

@corecontingency commented on GitHub (Dec 16, 2019): It works! After compiling with the patch, I added `noblacklist /proc/config.gz` to the profile. Shown below is what chrome://sandbox shows in brave running under firejail: ![brave_fixed](https://user-images.githubusercontent.com/54042889/70952962-1b2c7a80-2025-11ea-95d8-90690ce52eaa.png) Now for the discussion about how much danger this adds to the sandbox...

gitea-mirror commented

2026-05-05 08:30:30 -06:00

Author

Owner

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

@corecontingency Thanks for testing/confirming the patch works.

I made a PR in https://github.com/netblue30/firejail/pull/3087 awaiting review. Let's move any discussion about the patch to the PR.

@ghost commented on GitHub (Dec 17, 2019): @corecontingency Thanks for testing/confirming the patch works. I made a PR in https://github.com/netblue30/firejail/pull/3087 awaiting review. Let's move any discussion about the patch to the PR.

gitea-mirror commented

2026-05-05 08:30:31 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 17, 2019):

/proc/config.gz does not exists on all distros (for example fedora). what happens if we hide it?

@rusty-snake commented on GitHub (Dec 17, 2019): `/proc/config.gz` does not exists on all distros (for example fedora). what happens if we hide it?

gitea-mirror commented

2026-05-05 08:30:32 -06:00

Author

Owner

@corecontingency commented on GitHub (Dec 17, 2019):

That might work too. I imagine that if it cannot find /proc/config.gz it checks the config file in /boot/. Possibly it is getting confused on Manjaro/Arch and not checking /boot/ because /proc/config.gz is present in the sandbox, just unreadable?

Wait, nvm, /boot/ is unreadable entirely in firejail.

@corecontingency commented on GitHub (Dec 17, 2019): That might work too. I imagine that if it cannot find /proc/config.gz it checks the config file in /boot/. Possibly it is getting confused on Manjaro/Arch and not checking /boot/ because /proc/config.gz is present in the sandbox, just unreadable? Wait, nvm, /boot/ is unreadable entirely in firejail.

gitea-mirror commented

2026-05-05 08:30:33 -06:00

Author

Owner

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

@corecontingency I've been doing some more research on Brave and I might have found a way to have our cake and eat it too. Translation: it might not be needed to make any changes to firejail after all and still be able to keeo Brave's native sandbox intact. It all boils down to bypassing the (sandbox) checks in /usr/bin/brave on Arch Linux and derivatives. This issue doesn't exist on Debian/Ubuntu and hopefully other Linux distributions.

Would you be willing to do another test to confirm/deny whether my logic holds up? If so, make sure you don't have firejail patched with the tentative stuff I provided above and run the below from a terminal:

$ firejail --ignore=quiet /usr/lib/brave-bin/brave

For me this starts Brave without any major hickups, showing the exact same (mostly) green sandbox status cfr. the image in your earlier post. This would keep the firejail sandbox as tight as possible, whatever the state of /proc/config.gz, which is the better option here IMHO. Feel free to disagree, shoot holes in my argumentation etcetera. We really need to fix Brave somehow, that's the only goal here... TIA.

@ghost commented on GitHub (Dec 18, 2019): @corecontingency I've been doing some more research on Brave and I **might** have found a way to have our cake and eat it too. Translation: it might not be needed to make any changes to firejail after all **and** still be able to keeo Brave's native sandbox intact. _It all boils down to bypassing the (sandbox) checks in `/usr/bin/brave` on Arch Linux and derivatives_. This issue doesn't exist on Debian/Ubuntu and hopefully other Linux distributions. Would you be willing to do another test to confirm/deny whether my logic holds up? If so, make sure you don't have firejail patched with the tentative stuff I provided above and run the below from a terminal: `$ firejail --ignore=quiet /usr/lib/brave-bin/brave` For me this starts Brave without any major hickups, showing the exact same (mostly) green sandbox status cfr. the image in your earlier post. This would keep the firejail sandbox as tight as possible, whatever the state of /proc/config.gz, which is the better option here IMHO. Feel free to disagree, shoot holes in my argumentation etcetera. We really need to fix Brave somehow, that's the only goal here... TIA.

gitea-mirror commented

2026-05-05 08:30:33 -06:00

Author

Owner

@corecontingency commented on GitHub (Dec 18, 2019):

Seems like this works, good idea! Used a fresh Manjaro vm with AUR packages firejail-git and brave-bin (all defaults) installed. The browser seems to work fine too, it saves your tabs, addons, and settings.

Downside of this method is that it might be harder for the end-user. I don't think firecfg could use a symlink in /usr/local/bin to translate a call of brave from the desktop file to firejail /usr/lib/brave-bin/brave. If this is true, after noticing the sandbox is broken in brave, users would have to head to /etc/firejail/brave.profile, and (presumably) read a comment saying to make a copy of the brave desktop file, put it in ~/.local/share/applications/, and replace the line Exec=brave %U with Exec=firejail /usr/lib/brave-bin/brave %U in the desktop file if running Arch/Manjaro.

This isn't too much of a hassle, but something to keep in mind.

@corecontingency commented on GitHub (Dec 18, 2019): Seems like this works, good idea! Used a fresh Manjaro vm with AUR packages `firejail-git` and `brave-bin` (all defaults) installed. The browser seems to work fine too, it saves your tabs, addons, and settings. Downside of this method is that it might be harder for the end-user. I don't think `firecfg` could use a symlink in `/usr/local/bin` to translate a call of `brave` from the desktop file to `firejail /usr/lib/brave-bin/brave`. If this is true, after noticing the sandbox is broken in brave, users would have to head to `/etc/firejail/brave.profile`, and (presumably) read a comment saying to make a copy of the brave desktop file, put it in `~/.local/share/applications/`, and replace the line `Exec=brave %U` with `Exec=firejail /usr/lib/brave-bin/brave %U` in the desktop file if running Arch/Manjaro. This isn't too much of a hassle, but something to keep in mind.

gitea-mirror commented

2026-05-05 08:30:34 -06:00

Author

Owner

@Vincent43 commented on GitHub (Dec 18, 2019):

@glitsj16 this approach will be hard to propagate to users as we can't really mandate how they launch brave. I still believe my proposition from https://github.com/netblue30/firejail/pull/3087#issuecomment-566576207 will work better.

@Vincent43 commented on GitHub (Dec 18, 2019): @glitsj16 this approach will be hard to propagate to users as we can't really mandate how they launch brave. I still believe my proposition from https://github.com/netblue30/firejail/pull/3087#issuecomment-566576207 will work better.

gitea-mirror commented

2026-05-05 08:30:34 -06:00

Author

Owner

@ghost commented on GitHub (Dec 19, 2019):

@corecontingency Thanks for your response and analysis. After further deliberation it is indeed much better to go with @Vincent43's suggestions. I've updated the relevant PR accordingly.

@ghost commented on GitHub (Dec 19, 2019): @corecontingency Thanks for your response and analysis. After further deliberation it is indeed much better to go with @Vincent43's suggestions. I've updated the relevant PR accordingly.

gitea-mirror commented

2026-05-05 08:30:35 -06:00

Author

Owner

@Vincent43 commented on GitHub (Dec 20, 2019):

This should be fixed by 81997259ef

@Vincent43 commented on GitHub (Dec 20, 2019): This should be fixed by https://github.com/netblue30/firejail/commit/81997259ef3d28193e806d1e413c562927fd7631

Rows
Columns

[GH-ISSUE #2944] Firejail breaks Brave browser default sandboxing #1838