BDbdahz·Oct 24, 2023
So what's the difference between nsjail[1] and bubblewrap[2]?
[1] https://github.com/google/nsjail
[2] https://github.com/containers/bubblewrap
In Server-side sandboxing: Containers and seccompcontainers
bubblewrap
C2016–2026
containers / bubblewrap
bubblewrap
Low-level unprivileged sandboxing tool used by Flatpak and similar projects
80Distinct people
94Mentions
1Explicit recommenders
9.5KGitHub stars
What to know before exploring
What it is
Low-level unprivileged sandboxing tool used by Flatpak and similar projects
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
If you want to learn more about container security I recommend https://blog.jessfraz.com/ and https://github.com/projectatomic/bubblewrap
wmf used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year94 dated mentions
Observed mentions: 2016-08-07 13:03:40 UTC to 2026-10-10 15:11:41 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 14 | 1 | 13 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 12 | 1 | 11 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 11 | 1 | 10 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 24 | 0 | 24 |
What Hacker News says
12 sources> They're not lightweight and easy enough to use.
```
$ alias SafeRun="bwrap --ro-bind / / --dev /dev --proc /proc --unshare-all --tmpfs ~ --bind ~/Untrusted ~/Untrusted"
$ SafeRun python3 ~/Untrusted/RandomScript.py
$ SafeRun ~/Untrusted/RandomExecutable
```
This is basically manually invoking what Flatpak does:
https://github.com/containers/bubblewrap
This is also useful for more than just security. E.G., you can test how your app would behave on a fresh install by masking your user configuration files. I personally also have a tool that uses it to basically bundle all dependencies from an entire Linux distribution in order to make highly portable AppImages— Been meaning to post that, will get around to it eventually maybe.
The flags above should hide your user data (`--tmpfs`), disable network access (`--unshare-all`), hide/virtualize
Read the rest
devices and OS state (`--dev` and `--proc`), and make the rest of the root filesystem read-only (`--ro-bind`— Including the insecure X11 socket in `/tmp`, which you might want to expose for GUI apps).
Check them against `bwrap --help`; I might have omitted one or two more things you'd need.
While trying to find out more comparison information, found this light on details issue:
https://github.com/containers/bubblewrap/issues/81
It mentions nsjail and minijail.
In Firejail: Light, featureful and zero-dependency security sandbox for LinuxBubblewrap – Low-level unprivileged sandboxing tool used by Flatpak
91 points · Open discussionSee also Bubblewrap[1]. I use Bubblewrap all the time, because it's just useful, and a bit easier than doing things with unshare directly.
To compare and contrast: bubblewrap is lower level, and is great for embedding or using in one-off invocations, whereas firejail is more oriented towards adding a bit of hardening to everyday applications like Firefox via built-in and custom profiles.
For example, you could temporarily override a path doing something like this:
bwrap --bind / / --bind /tmp/myoverride /usr/lib/qt5.15.2/plugins/kf5 -- ...
to, say, override the KDE plugins while testing. This is useful for me since it's rather challenging during development to actually get KDE apps to reliably load my plugins on NixOS: I think kio slaves are probably wrapped and getting other environments injected into them. Rather than bother with a
Read the rest
ny tricky hacks, Linux namespaces make it relatively easy to test regardless.
Bubblewrap is used internally by Flatpak and others.
https://github.com/containers/bubblewrap
Plain systemd can run docker containers, and keep them up if they crash. (Yes, systemd can be a useful thing sometimes!)
Also, Docker and Podman know how to restart containers if needed, depending on a policy you set.
If you want something even smaller, take https://github.com/containers/bubblewrap or https://github.com/arachsys/containers and run them under the process monitor of your choice, like runit or s6.
In Keycloak – Open-source identity and access management interviewFlatpak is quite simple under the hood, it's just a wrapper around bubblewrap [0]. I'm not sure what you mean with integrating it with a CMake build.
[0]: https://github.com/containers/bubblewrap
In Red Hat dropping support for LibreOfficeBubblewrap is a good tool in this space https://github.com/containers/bubblewrap
In The Unix process API is unreliable and unsafe (2021)I recently wrote an autorunner[1] (like Entr[2] and Watchexec[3]) so I have some recent exposure to this problem. (I will be releasing it on Github shortly.) My autorunner allows running interactive programmes, so it is very sensitive to lingering child processes.
For the purposes of the autorunner, I use approach 1.1.3 (“always write down the pid of every process you start, or otherwise coordinate between A and B”) and leave it to the user to figure out what happens if the child process misbehaves with relation to any processes it starts.
However, I want to point out that approach 1.1.4 (“A should run B inside a container”) is easier to do than one might expect, and I'd like to plug one of my favourite utilities—Bubblewrap[4]. The Bubblewrap documentation says “[y]ou are unlikely to use it directly from the commandline, although that is
Read the rest
possible” but I have built some amazing little tools from it.
Try the following invocation:
bwrap --ro-bind / / --proc /proc --unshare-pid ps
This launches `ps` in a PID namespace with a new `/proc` (since `ps` will read from the host proc otherwise) and the root filesystem mounted readonly. Any procesesses within the PID namespace should have been created by the immediate command that `bwrap` launched. There are also flags `--die-with-parent` and `--as-pid-1` which can further reduce runtime overhead. If you really need a supervisor process, this can be as simple as a `/bin/sh` script that `kill TERM --timeout 1000 KILL` in a loop on everything it sees in `ps`.)
As you can see, there's a lot you can do with this tool with significantly lower overhead than using Docker. It has been my goal for some time to extract some of the functionality of Bubblewrap into a Zsh extension to allow accessing these mechanisms with even lower overhead. I think the creation of namespaces is a missing primitive in Linux shells, and being able to quickly construct namespaced environments allows for a style of safe, robust, simple shell scripting. e.g., if you create a mount namespace to run your script, you can actually be looser about parameterising file locations (since the namespace can ensure everything is exactly where you want it to be.)
[1] https://fosstodon.org/@dontusethsicode/110019380909461936
[2] http://eradman.com/entrproject/
[3] https://watchexec.github.io/
[4] https://github.com/containers/bubblewrap
I don't want to say too much, because I know our security isn't perfect, and some about of obfuscation adds some security. Once we move to a more secure model, I will happily tell you all what use used to use to sandbox code.
Soon we'll do real sandboxing, either ourselves through Docker, wasm, bubblewrap[1], etc, or an existing FaaS (Lambda, Deno Deploy, Cloudflare Workers) or FaaSaaS (Deno Subhosting)
[1] - https://github.com/containers/bubblewrap
In Show HN: Val Town – A Cloud Scripting SiteYou can have RAII with GCC extensions in C:
char *buf __attribute__ ((__cleanup__(free_buf))) = malloc(1024);
This calls free_buf(buf) when buf goes out of scope.
I’ve actually seen projects use it in the wild to close files or free memory in branchy functions. [1]
[1] https://github.com/containers/bubblewrap/blob/c54bbc6d7b78e7...
In Modern C for C++ peeps (2019)Such solutions exist already, see e.g. bubblewrap [1]. The Flatpak ecosystem is slowly trying to add protection by sandboxing applications using bubblewrap. However a contingent of the Linux community meets this with:
- Flatpak is terrible because it doesn't follow a file system hierarchy that was invented in the 70ies.
- Flatpak is terrible because my early 90ies package manager is the pinnacle of packaging.
- Flatpak is terrible because I only trust my distribution's packages.
- Flatpak is a security nightmare because it doesn't isolate every application now. (Which is not really possible, because applications/toolkits need to be adapted).
- Flatpak is terrible because now my applications cannot open arbitrary files anymore (including ~/.ssh).
Conservatism is what holds the Linux ecosystem back. We have seen this story before with syste
Read the rest
md. This is sad, because Red Hat and others are doing fantastic work modernizing Linux (see Flatpak, Fedora Silverblue, etc.).
[1] https://github.com/containers/bubblewrap