Does Flatpak weaken Chromium/Firefox's sandbox?

Continuing the discussion from Which Flatpaks and other resources should be included in the “Downloads” section? - #4:

I’ve heard this before, but couldn’t find anything about it online. Can you link some further reading on this subject?

There seems to be a need for a general information note on whether or not to install flatpak versions of Chromium and Electron-based applications.

IIRC Flatpak disables unprivileged user namespaces due to the increased attack surface they bring with them. Unfortunately, I’m fairly sure they’re utilized by Chromium/Firefox to tighten up the sandbox even more than what flatpak has.

Chromium Docs - Linux Sandboxing (

Security/Sandbox/Specifics - MozillaWiki

You can see that they mention them as being part of the sandbox. This isn’t the only issue with using a flatpak browser, but it’s one of the big ones.

The Chromium Flatpak is patched to use Flatpak’s nested sandboxing API, because it doesn’t have access to sandboxing APIs provided by the kernel. So it’s incorrect to state that Chromium’s sandboxes are disabled just because it’s running inside a container.

Flatpaks aren’t exactly the most effective sandboxes themselves. However, I haven’t seen any evidence that the sub-sandboxes created by Chromium within a Flatpak container are any less effective than Chromium’s normal sandboxes. If you or someone thinks that they are less effective in a Flatpak, I’d love to see actual evidence supporting that claim.

In chrome://sandbox layer 1 sandbox is yellow (SUID) within flatpak but normally it is green (namespace)

For Chromium builds which natively support Flatpak’s sub-sandboxing:

For Chromium builds which don’t and use zypak instead (i.e. Brave Browser) you will see “SUID” displayed, yes, but it is not Chromium’s old SUID sandbox even though it says it is:

Zypak works by using LD_PRELOAD to trick Chromium into thinking its SUID sandbox is present and still setuid, but all calls to it get instead redirected to another binary: Zypak’s own sandbox.

Additionally, even if it was using the official SUID sandbox, that sandbox is still maintained.

The Chromium sandbox has three main components: seccomp-filters, namespaces and chroots.

Seccomp-filters are stackable and the syscall is not blocked by Flatpak’s seccomp-filter, thus the Seccomp-part of the Chromium sandboxes should stay intact.

The creation of namespaces and chroots gets blocked by Flatpak’s seccomp-filter. Then there is flatpak-spawn which can be used to further sandbox or even let processes run on the host.

Pls check the namespace structure of Flatpak’s Chromium vs the official native Chrome with lsns -T. You will see a noticable difference and weakened site isolation. The native Chrome namespace structure is more fine-grained. Thus leading to better horizontal isolation.

Browsers are very complicated and follow a clear security model, since they have to run (potentially malicious) untrusted code many times a day. No project just arbitrarily adds namespaces without a good security reason, because it adds quite some complexity.

So if you change the namespace structure, you should definitely have a very good reason and an exceptionally good understanding of the browsers security. If you change it, you need to proof that this makes things better, or at least not worse, and not the other way around.

You will find different statements regarding Chromium’s SUID sandbox. I found statements that it has been phased out, other statements like the one you linked say that it’s not actively developed and only in maintenance mode. It is still available to users, but the use of unprivileged user namespaces is clearly Chromium’s preferred way and the resulting sandboxes are not the same.

For FF and Tor browser launcher the situation is similar. But they don’t even try to replace the namespace sandbox with flatpak-spawn. So you lose namespaces and chroots. This leads to weakened site isolation, weakened protection of the browser’s files (history, cookies, …) and also to less protection of the host OS. In the issue tracker about this topic, FF employees stated that they are aware of the missing namespaces and chroots, but downplay their importance. Side-note: They also never implemented a SUID sandbox, so users with deactivated unprivileged user namespaces have the same problem with missing namespace+chroot sandbox even though the about:support page makes you believe otherwise.

MicroOS already includes Firefox’s flatpak package and something similar is planned for Silverblue. Traditional Linux distributions should install it with the package manager, as recommended on Firefox’s support page. But should immutable Linux distributions prefer the “local Firefox installation in user’s account” method?

I wouldn’t use the Flatpak variant if you can get the browser through other ways.

Just to be clear. For the vast majority of apps it’s good that Flatpak blocks syscalls for namespace and chroot creation because they increase attack surface quite a lot and can lead to sandbox escapes. Just for already properly sandboxed applications it’s not a good thing, because you can sandbox individual processes in a multi-process program way stricter than if you put the program as a whole in a container sandbox, so the Flatpak sandbox won’t outweigh this.

The solution for Flatpak could be to manually approve apps like chromium to allow these syscalls or allow advanced users to specify a different seccomp-filter per app, with a fallback to the default filter.

Like I also said though, Flatpaks don’t even use Chromium’s SUID sandbox even if Chromium claims to be using it on the sandbox info page.

As far as Firefox, yeah I’m not sure. It could very well be that Firefox is worsened in Flatpak, but again I haven’t seen anyone share evidence to suggest that is the case either.

That doesn’t make sense. It’s the other way around. With the native install, browser devs are free to use the sandboxing they think is appropriate. That’s the gold standard. If other implementations deviate from that they have to prove that this doesn’t lead to less security, not the other way around. You can check that the sandboxes are significantly different yourself, if you don’t believe me ;).

Well which is it, is Mozilla’s development the gold standard for their browsers, or do they not understand the importance of certain sandboxing techniques? My reading of the issue you’re referring to is that Firefox’s sandbox was developed without the need for this in the first place, because they didn’t want to take the same approach as Chromium here, so a comparison between how important namespaces/a setuid helper is to Chromium compared to how important they are to Firefox doesn’t seem relevant.

The Firefox Flatpak is official and developed by Mozilla, so the burden of proof is actually on anyone claiming one version of Firefox shipped by Mozilla is worse than another version of Firefox shipped by Mozilla.

The gold standard is the native installation, because it is free to do whatever is needed.

That’s your interpretation and I have to disagree. Namespaces and chroot have a clear purpose in browser sandboxing and are not some optional goodie. That’s not just my opinion, but can also be found in research papers. Which technology is used in the FF browser which can replace them?

It is relevant to browser security and also relevant to users who don’t use unprivileged user namespaces.

Not the first time that Mozilla sacrificed on security just to ship something. Not having shipped a proper SUID sandbox in the past when most distros didn’t use unprivileged user namespaces is a good example (today most kernels have them activated).

I’m just saying that you’re welcome to your opinions when you’re evaluating a browser, but as far as deciding what we’re going to recommend on the site, that has to be based in reliable fact, so we have to defer to Mozilla’s browser expertise in this case unless their methods are provably deficient. Right? This is basically hearsay when it comes down to it.