The way I see it with browsers in linux is that you have a trade-off to make: install the native version from distro’s repositories and if an attacker escapes browsers sandboxing (for which there has been some recent bugs discovered) it could gain same permissions as the user. or install the flatpak version that adds an outer layer to protect your home but it also weakens browsers own internal sandboxing, which might just be a net negative.
To answer your question directly: while bubblewrap is a great tool, wrapping a native browser in a custom bwrap setup is generally not recommended, it often ends up being a net negative or neutral for browser security.
Here is why:
Interference with Internal Sandboxing: Chrome, Brave, and Firefox rely on unprivileged user namespaces and custom seccomp-bpf filters to isolate individual renderer tabs and GPU processes. Nesting user namespaces via an outer bwrap container frequently breaks or forces the browser to degrade its internal sandbox.
Seccomp Conflicts & Maintenance: Browser update cycles frequently change system call patterns. Unmaintained custom seccomp filters can easily break features (DRM, VA-API, WebGL) or force users to relax rules, inadvertently introducing security holes.
The recommended right now (things may change, there are some work happening to improve this on Flatpaks):
MAC (Mandatory Access Control), AppArmor or SELinux are generally preferred for native browsers because:
They restrict what file paths, IPC, or network capabilities the browser process can access on your host.
They operate out-of-band without interfering with the browser’s ability to create its own internal namespaces or seccomp filters.
If you want a native browser setup, the recommended path is using the distro package alongside a strict AppArmor/SELinux profile. If you want maximum isolation, containerizing/virtualizing at a higher layer (e.g., Qubes OS or dedicated disposable VMs) is far more effective than layering namespace wrappers on top of each other.
I didn’t, good call. I assumed they went the standard route.
I guess, the only pitfall that I can identify is maintenance burden. Because browser rendering engines update frequently, maintaining custom BPF seccomp filters requires staying on top of upstream changes to ensure future updates don’t break features or cause subtle fallbacks.
The problem with sandobxing that operates in kernel/root is that a flaw in the sandbox might lead to root escalation where not sandboxing it would’ve reduced the blast radius. both firejail and apparmor(and snaps even more) had instances of that happening. that is why I like bubblewrap a lot more
Have been reading the source code since morning here, the seccomp filters seem very generic and things a browser should never touch anyway. the code seems well thought.
WebKitGTK shares many of the same features of regular WebKit, sans some stuff that are iOS/macOS/Apple specific. It is the only browser to support proper sandboxing in Flatpak but said sandboxing is notably weaker than native (non-Flatpak) Chromium.
The benefits of using these tools often outweighs the rare occasions, where they can be used to escalate privileges. Even in cases where these bugs occur, they are often only exploitable from outside the sandbox, by unsandboxed processes.
benefit with bubblewrap+seccomp filters seem that it has no down side. nothing weakened and no extra attack surface. if it fails then we are back to native browsers
There are some things you can’t do or can’t do well with bubblewrap, eg. firewalling, domain transitions, domain to domain communication rules and rules with wildcards.