Isolate the Unsafe Browser container more tightly

intrigeri
2026-04-06T14:36:39Z

Since !838 we run the _Unsafe Browser_ with `run_in_netns`, which uses `bwrap`, so effectively we get new, isolated mount and network namespaces… which was exactly what `run_in_netns` was created for. But here we might want to expect a b...

Since !838 (merged) we run the Unsafe Browser with run_in_netns, which uses bwrap, so effectively we get new, isolated mount and network namespaces… which was exactly what run_in_netns was created for. But here we might want to expect a bit more from the container we're setting up.

Would it work to make the sandbox stricter by asking bwrap to unshare more resources? As of 0.6.2, bubblewrap can also manage these other namespaces: user, ipc, pid, uts, cgroup.

Could we forbid microphone access?

https://github.com/flatpak/xdg-desktop-portal/issues/615

Unsafe Browser - Sandbox escape by sniffing aud... (#19596)

The sandbox is currently mostly useless since it does --bind / / so we really only have sandboxing through AppArmor for the Unsafe Browser at the moment.

Don't share the whole /home, as a second layer in case our current security boundary for file access (AppArmor policy) fails (originally reported in tails/tails#20737, credits: ROS)

Avoids an exploited Unsafe Browser writing to e.g. .bashrc

In case Unsafe Browser loads stuff from e.g. ~/.local or ~/.cache, an attacker who can write there could change the startup URL of the browser to an attacker-controlled URL, logging the real IP of the user

Additionally, we have AppArmor rules set up for the Unsafe Browser, which suggests we particularly mean to sandbox it. But we merely intended to "sandbox" it as well as the Tor Browser.