Security problems with Flatpak Browsers (Firefox, Chromium), bubblejail, seccomp, user namespaces

(I wrote this post a while ago as a comment on Lemmy, where I cannot search or link it, so here as a kinda general discussion)

It is a great idea but the concept has issues.

This issue helps to understand it

seccomp background

libseccomp is a long established security “firewall for syscalls”, it allows to restrict what actions programs can perform on the system.

I dont know what exactly these are, as they are low level, but one of these actions is “create an unprivileged user namespace”.

Flatpak uses a single, “badness enumerating” seccomp filter, which means they block the syscalls “A”, “B” and “C” for all programs. All others are allowed, and (see the issue) programs need to define a more strict one individually. There is no modularity here.

user namespaces

A namespace is a virtual filesystem on top of the “real” one, where certain system files are mounted to. This means unprivileged programs can suddenly do “OS stuff”.

contra user namespaces

Many distros like Debian (and Arch) didnt enable this feature for a long time, because user namespaces mean that unprivileged userspace programs, like your browser, can suddenly access low level system components like the filesystem.

If there now is a bug in such a component (like a driver for some random filesystem like reiserfs), user namespaces allow the program to directly access a way more privileged area, escape here and possibly get root access.

That’s why these drivers should be blocklisted when not used, for example exotic or ancient filesystems.

This would not be possible when not using user namespaces.

Flatpak has a seccomp filter that blocks the creation of user namespaces, to avoid this low level system access. Which is a very good thing, but the missing modularity doesn’t allow anything else!

pro usernamespaces

Over time even slow pacing distros like Debian enabled user namespaces.

Today they are the core feature of bubblewrap, podman, docker, (and thus distrobox and toolbox)…

The concept is that a rootless binary, running in userspace, can access system components which would normally require root.

Firejail is the opposite example, it is a suid binary and sandboxes apps also when user namespaces are disabled. Chromium has a fallback suid sandbox which also runs as root, same with bubblewrap after the modification by 34N0 implemented in the “no userns” images of secureblue.

(You just need to change the permission of the binary to suid)

The problem is, a suid binary has root access. If there is a flaw in it, which was the case with firejail, the “nice and secure isolated app” could now use the suid binary to escalate its privileges to root level, more than what it could have done without it.

Browsers and Sandboxes

A browser is basically a platform to run “apps” on. Nearly all websites nowadays require executable code, which means browsers are the attack surface for malware. Scrap your verified Flathub or well maintained distro repository, a single website could use a weakness and break your system.

This was a thing back in the time… crazy huh?

Chromium (Chrome, Edge, Brave, Vivaldi, Opera, …) has the said suid sandbox as a fallback, I guess implemented back when user namespace sandboxes were not adopted enough.

But it normally uses a user namespace sandbox for process isolation, every tab runs in a different process, on Android too.

Firefox also uses user namespace sandboxes for tabs.

These user namespace sandboxes restrict the filesystem access.

Both use some form of BPF sandbox (Firefox using seccomp-bpf) to restrict the sub-processes’ (tabs etc) access to system calls.

This is called “stacking seccomp filters” and at least browsers often use that (while all other programs can use it too, also Flatpaks).

Flatpak and Chromium

Chromium relies on the ability to create sandboxes, with a suid binary (the strange not really used fallback method) or with user namespaces.

So much that it straight up doesn’t run if it cannot do that. The same goes for Electron apps, which are a browser platform running a single or very few processes.

This is why zypak was created. It redirects the calls of Chromium to flatpak, so it uses the builtin Flatpak sandbox for isolating the filesystem instead.

As I said, all Flatpak apps (and thus all processes) use the same seccomp filter if they dont implement their own seccomp stracking, like Browsers do.

Chromium uses BPF for all processes.

The lack of modularity means that most other app devs will not add their own hardened filters though.

I assume that zypak is less secure than the native sandbox, which is battle tested by Google, Microsoft and more companies. But as it’s job is just filesystem sandboxing, this could very likely be wrong.

It uses a filesystem sandbox (additionally to the BPF syscall isolation), it is not suid and uses user namespaces. It just needs a security audit and a bit of pentesting.

Flatpak and Firefox

The Firefox Flatpak is official.

What the heck?

Thats what I asked myself and found this informative issue.

Right now we just fork(), so replacing that with flatpak-spawn would cause a massive increase in memory usage? You would no longer have CoW sharing of memory.

So Firefox would need big architectural changes (implementing a fork server) to support a sandbox like Flatpak’s. It uses copy-on-write to save Memory and be more efficient.

Chromium works fine, as it uses zygote, the fork server also used on Android.

it’s not clear to me the “Flatpak Sandbox” it’s creating is comparable to what we have now (even with just seccomp-bpf). We launch our subprocesses with specific, nailed down sandboxes.

If Chromium uses BPF too, they should compare that. They lack an entire sandboxing layer!

Fair usage in Flatpak

To sum it up:

Electron apps are fine to be ran as Flatpaks. The zypak sandbox may not isolate the processes from another as well as the normal one does, but they are controlled and known code.

Electron uses Chromium because of laziness, not because it needs the security of the platform. Daniel Micay, the creator of GrapheneOS, would also list a few very technical things why Electron has crippled security features of Chromium.

Thunderbird is using Firefox similar to Electron, just as a platform for known code, so this will be fair too.

Flatpak Firefox… is very likely lesssecure. If you use UBlock Origin with some filterlists, and an opt-in NoScript setup (which I highly recommend for privacy and security), the risk of running malicious code is way lower.

But the risk is literally getting malware, losing all your data, getting breached or intruded. So why leave out the filesystem sandboxing?

Isolating the Browser itself

Flatpak isolates the browsers from the system, which is really nice. If there is a weakness in the browser platform, a process could not just escalate and access everything Firefox can.


So isolating the browser from the system using Bubblewrap, a modern and rootless sandboxing tool, sounds like a good idea.

The only issue is the always-the-same seccomp filter. The best solution would be a fix for the issue at the beginning, but for now we can use bubblejail.

It is a tool that makes the creation of bubblewrap and seccomp filters easy, and adds Desktop entries to launch existing apps through that sandbox.

For some reason it doesnt work at all anymore for me… but it did in the past. It is certainly not ready, but with some helping hands it can fix all the gaps, where system apps are needed for certain abilities.

May that be a VPN app, Nextcloud-client adding icons to your task manager, an IDE like VSCodium, Zed, Lapce, Kate… or isolating all your system apps!

So currently I use Fedora Firefox, which is very well maintained and checked for security build flags.

I will continue trying to get bubblejail running, but Firefox implementing a fork server will be the real, very very needed change. Then it can use zypak (or a fork of it) and be more secure.

I don’t think you’re interpreting that flatpak issue correctly. To quote a comment there:

Seccomp filters are stackable, I think all browsers already use their own tight seccomp filtering on top of what flatpak uses.

Any app can do that, you don’t need flatpak help.

The issue is about allowing app manifests to tighten flatpak’s seccomp filter as easy way to harden apps that don’t do their own sandboxing. Modern browsers already implement filters for various process roles (network, renderer, etc.), and those work unmodified inside the flatpak sandbox.

In other words, this is incorrect. Zypak (or the patch applied to Chromium itself) only affects the namespace layer (filesystem sandbox). Here’s a quote from the author of the Chromium patch and zypak:

That being said, it’s worth noting Chromium’s sandbox is two layers, the second being a rather strict BPF sandbox, and that one is entirely unmodified. The first layer is primarily to block filesystem access, which has been tested and confirmed to work here (partly because we’ve had files end up missing that we needed to be able to access :sweat_smile:)

It certainly would be nice if the patch were upstreamed and formally audited, but it doesn’t seem especially high-risk.

Chromium uses a fork server called zygote. Firefox is working on their own fork server, which should hopefully make flatpak namespacing viable. But notably, they claim that their sandbox is designed to be secure without the namespace layer.


Yes for sure. A modular set of filters per app would be good.

I know that browsers do that and never said anything against that fact. The issues are

  • the default seccomp filter is not completed enough
  • it still blocks browsers from creating user namespaces

True, overlooked that. I will edit it.

Thanks for that info! Very interesting, yes zygote is also used in Android. Which means… zypak could be used to isolate Android apps?

Interesting, didnt know the term “fork server”. Only know that firefox forks the process, which would not work

Thanks to your comments @chrisawi I fixed a lot of mistakes. It should be nearer to reality now :wink:

Every time I see firejail I think :

sandbox -X -w 1920x1080 -H temphome -T tmp -t sandbox_web_t


Run the cmd application within a tightly confined SELinux domain. The default sandbox domain only allows applications the ability to read and write stdin, stdout and any other file descriptors handed to it. It is not allowed to open any other files. The -M option will mount an alternate homedir and tmpdir to be used by the sandbox.

If you have the policycoreutils-sandbox package installed, you can use the -X option and the -M option. sandbox -X allows you to run X applications within a sandbox. These applications will start up their own X Server and create a temporary home directory and /tmp. The default SELinux policy does not allow any capabilities or network access. It also prevents all access to the users other processes and files. Files specified on the command that are in the home directory or /tmp will be copied into the sandbox directories.

If directories are specified with -H or -T the directory will have its context modified with chcon(1) unless a level is specified with -l. If the MLS/MCS security level is specified, the user is responsible to set the correct labels.


Security-Enhanced Linux secures the sandbox processes via flexible mandatory access control.

The sandbox processes execute with the sandbox_t SELinux type. You can check if you have these processes running by executing the ps command with the -Z qualifier.

1 Like

Could you please sum it up for non-tech people? What would be the safest way of running Firefox? Using Firefox from the Fedora repository, using the one directly distributed by Mozilla as a tar.gz or the flatpak version?

I and many Fedora people will tell you, that the safest way to run it is using the Fedora RPM from the repos.

The Fedora Firefox may be a tiny bit slower in releases, but adds more build flags that sometimes may make it more secure.

Firefox does not have a way to use flatpak-spawn to isolate tabs and other processes into their own little sandboxes. It can just use seccomp-bpf which Mozilla devs assume as being enough, but the normal sandbox is still missing.

On Chromium based browsers, they are compatible with flatpak-spawn using the hack zypak, so they can use both methods of sandboxing.

Seccomp sandboxes are not restricted by Flatpak. Filesystem sandboxes dont work on Firefox at all, and may be way less strict on Chromium.

The single benefit for security is, that the browser itself is isolated from the OS. But if you use it as a platform and store passwords, credit card info etc in there, you should focus on the best process isolation possible.

1 Like