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.
AppArmor is something I wished I understood how to use. Unfortunately, I don’t even though I’ve spent a significant amount of time trying to figure it out.
SELinux is even worse. I just hope that when I see the status `targeted, enforcing` it all just magically works and I don’t have to worry about anything
Honestly, I can barely remember anything about it now. This was after people started seeing the banner at the top of their screens in Firefox and Tor (and forks) that were downloaded either through flatpak or maybe snap (can’t remember)
I’ve looked and read through guides and it seems like none of them are perfect (not for beginners anyway). An example is Firefox’s website you would land on once you clicked that banner at the top. It said something to effect of “If the file doesn’t already exist, create a new one and name it yadayada whatever”. I learned real quick that it’s not as easy as it sounds. It took me ages just to figure that out (which I’ve already forgotten btw) and it’s little stuff like that.
After that, I’m sure there was something else I got hung up on that made me finally give it up but I don’t recall what that was now.
Bubblewrap relies on user namespaces for sandboxing. While these provide isolation, they also expand the kernel attack surface and have been the root cause of numerous privilege escalation vulnerabilities (CVE-2022-0492, CVE-2021-3493, Dirty Frag, and many others).
Rather than relying on a single sandboxing layer, I’d argue for a defense-in-depth approach:
Run the browser inside a rootless Podman container (not Docker — no privileged daemon)
Drop unnecessary Linux capabilities
Mount the container’s root filesystem read-only and then mount only necessary dirs from host to container for persistence.
Apply --security-opt no-new-privileges
Generate a tailored SELinux policy for the container using udica
Keep the browser’s own internal sandbox intact
This gives us multiple independent layers: Podman container + capability drops + no-new-privileges + read-only rootfs + SELinux confinement + browser sandbox. Even if one layer is bypassed via a kernel bug, the remaining layers still contain the damage. That’s a significantly stronger posture than "browser sandbox + bwrap.
Podman rootless also uses userns, so the underlying kernel risk isn’t eliminated it’s just surrounded by enough independent controls that exploitation becomes much harder to turn into a meaningful escape.
The only benefit of your solution is Selinux. Selinux on its own wouldn’t be a security boundary in this case, at least, if you use Fedora’s refpolicy due to some limitations of this policy for desktop applications. Everything else can be done with Bubblewrap as well. Also you need to add a really important layer, which is seccomp. Without a taylored seccomp filter, attack surface of the kernel is huge.
Another downside is that bubblewrap to my knowledge reqyures you to have usernamespaces to be enabled, which get used it a LOT of privilege escaltion exploits.
So does rootless podman or any Chromium-/FF-based browser. Chromium does have a SUID sandbox as a workaround, but it is not feature-equivalent to the unpriv. userns sandbox.