Bubblewrap, or bwrap, is a low level tool that builds an unprivileged sandbox on Linux using user namespaces. It gives you the pieces, such as an empty mount namespace and read only bind mounts, but no ready made security policy. Your arguments decide how strong the sandbox is.
What bubblewrap is
The project describes bubblewrap as a low level unprivileged sandboxing tool used by Flatpak and similar projects. Its page explains why it exists. Container tools designed for administrators and orchestration systems are not suitable to hand to unprivileged users, because it is trivial to turn such access into a fully privileged root shell on the host. Bubblewrap instead uses the kernel's user namespaces so that any user can build a sandbox.
The project says it historically supported a setuid mode for systems without unprivileged user namespaces, but that mode has been removed. It also sets the no new privileges flag to turn off setuid binaries, the traditional escape from chroots.
How it works
Bubblewrap creates a new, empty mount namespace whose root sits on a memory backed filesystem that the host cannot see and that is cleaned up when the last process exits. You then construct the visible filesystem with options. The project's trimmed example runs a shell that reuses the host's usr directory read only:
bwrap \
--ro-bind /usr /usr \
--symlink usr/lib64 /lib64 \
--proc /proc \
--dev /dev \
--unshare-pid \
--new-session \
bash
The project notes this is an incomplete illustration. The point is that the process sees only what you bind in.
The part people miss
The documentation is direct: bubblewrap is not a complete, ready made sandbox with a specific security policy. Some uses want a real security boundary, while others only want to rearrange the filesystem layout for the process. The level of protection is entirely determined by the arguments passed. Whatever program builds the command line, whether a framework like Flatpak or an ad hoc script, owns the security model.
That has a practical consequence. A one line script that binds your whole home directory writable gives you a sandbox in name only. The maintainers also say it may increase a logged in user's ability to mount denial of service attacks, while they believe it does not allow privilege escalation.
When it fits
| Situation | Fit |
|---|---|
| Run a build or converter with only the project folder visible | Good fit, with read only binds for everything else |
| Isolate a desktop app on Linux | Good fit, which is what Flatpak does |
| Run hostile code from strangers | Weak fit alone, since it uses the shared host kernel |
| Need a ready made policy without writing arguments | Not designed for that |
For the last two, look at a stronger boundary, see which sandbox fits which code.
A starting recipe
- Start from an empty root and bind in only the directories the tool needs, read only.
- Bind the working folder writable and nothing else.
- Unshare the process and network namespaces unless the tool needs them.
- Add a system call filter if your wrapper supports one.
- Test by trying to read a file outside the sandbox, and confirm it fails.
For another unprivileged restriction mechanism, see what Landlock does.
Safeguard scans the dependencies of the tools you sandbox, with a free scan at gold.safeguard.sh/scan.
Quick check
Is bubblewrap a container runtime?
It overlaps with one, but the project describes it as a low level sandboxing tool for unprivileged use, not an orchestration system.
Does using bubblewrap guarantee isolation?
No. The project states the protection level is determined entirely by the arguments you pass.
Sources
Last reviewed: 19 October 2026.
