HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
containers
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
REPOSITORY AT A GLANCE

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.

05101520252016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 11 mentions; 1 submissions, 10 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 24 mentions; 0 submissions, 24 comments. Incomplete calendar period.2026*

* 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
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC312
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC303
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC505
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC514
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC716
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC14113
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC12111
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC808
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC11110
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC24024

What Hacker News says

14 sources
The owner module can control outbound communication by uid/gid. [1] There are no modules to handle things by PID AFAIK. This can however be accomplished by SELinux and Apparmor custom rules but that is a loaded topic. Firejail [2] and Bubblewrap [3] can put limits on application capabilities and/or take away network access. Firejail has default policies for many applications, all of which can be overridden by user configurations in their home directory. Firejail leverages Linux Capabilities and AppArmor. For example, when I launch VLC even if it were configured to pull down album information, it could not. If one day they added default-enabled telemetry to VLC it would go nowhere. A round-about and heavy handed way to manage communications by PID would be to isolation applications in their own VM or container and map the VM or conta
Read the rest
In Microsoft is phoning home the content of PowerPoint slides
Right, this is a real fear on closed platforms like OSX and Windows. Microsoft is actually going to this direction with the pluton platform. But this also means the "personal" from PC gets taken away. The thing is, software developers themselves can't achieve lock-in and take over the control how the code gets executed on your PC if the platform you are running does not provide this feature in the first place. So typical sandboxing on Linux will never go in the ways of DRM, or give control to the publisher of the software. Your fear will become true, if software starts targetting or even preferring a trusted platform instead of a open platform like the PC we currently have. But this is not fault of a sandboxing technology itself, it's the fault of companies looking to have control over their product and their users. Unfortunately, I can s
Read the rest
ee future going towards with trusted platforms, where users on non-trusted system will be heavily handicapped, for example netflix not allowing 4k streaming, multiplayer games not allowing you online, or putting you on different servers etc... Valve's linux + proton push may make developers keep targeting the proton WIN32 subset in the future, but we'll see... Regarding modding, many online games do not allow it even in the current form, requiring you to play offline if the game is modified, or connect to a custom server. By the way, on linux you can easily achieve a sandbox using bwrap https://github.com/containers/bubblewrap
In Reverse Engineering Dark Souls 3 Networking
It's hard to make it practical without linking a whole lot of your local environment in. Remember it's death by a thousand cuts - every time you need some new thing, you just add it without considering the consequences too much. Probably lots of people doing this with their whole home directory linked in read/write. Recently I got a little concerned about this and made myself a basic safety harness with the bubblewrap[1] tool: rather then going all out, I just lock the mount namespace to readonly for everything except the directory I execute it in. Which is at least some protection against system mods or wide-spread home directory destruction. What's a lot more of a problem is trying to protect truly vital files - i.e. SSH keys and the like - which are also things you're likely to have bound into your VM anyway. selinux is a much better s
Read the rest
olution there (but so hard to administer as to be almost useless, though I do really like Fedora's default scopes and have used them successfully). [1] https://github.com/containers/bubblewrap
In Node.js packages don't deserve trust
Note that a sandbox escape is often possible via TIOCSTI (CVE-2017-5226) [0] unless a special flag (--new-session) is used. Bubblewrap is aware of this, yet their documentation gives no indication that this flag is necessary to produce a secure sandbox. In --help, the documentation of --new-session is simply "Create a new terminal session," which severely understates its importance. It's frustrating to have such a useful tool be knowingly easy to misuse. [0]: https://github.com/containers/bubblewrap/issues/142
In Bubblewrap: Unprivileged sandboxing tool for Linux
Also consider Bubblewrap, which is what Flatpak uses under the hood. There are a couple of meaningful differences which may or may not be important to you: https://github.com/containers/bubblewrap#related-project-com... Personally, I like that Bubblewrap doesn't require the same level of privileging, and I like the consistency with Flatpak. It feels like an unnecessary increase in attack surface to be running completely separate sandboxing tools. But, there are also advantages to Firejail, I'm not saying you shouldn't use it. Reminder that unless you're doing complicated things with X sessions, Wayland is an important part of sandboxing and you should probably assume that any graphical malware will be able to break out of a sandbox on an X system (not because it's impossible to sandbox X, just that if you're dabbling in this stuff you're
Read the rest
probably not sandboxing it correctly). Honestly, you should probably use something more robust than either of these programs if you're worried about malware. I just think it's easier and safer to use a VM and importantly I think you're less likely to shoot yourself in the foot using a VM (although it is still possible for malware to escape VMs depending on how they're configured). I'm not a security expert, take that advice with many grains of salt. ---- A lot of these programs (in my opinion) lack really good documentation about how to work with them. You kind of need to know the basics of how they work before you start. I think if anyone ever wanted to create a really detailed guide about what the different options are, what the considerations are, stuff like that, there's a lot of opportunity there to single-handedly drastically improve the accessibility of these tools. Most guides I have seen assume you know already know how the underlying permissions, process isolation, network stuff all works -- even some of the better guides on Arch (https://wiki.archlinux.org/title/Firejail, https://wiki.archlinux.org/title/bubblewrap) are just not accessible unless you're willing to go down those rabbit holes and figure out all of the terminology being used. It's not that the documentation doesn't exist, and once you understand how the command line options work they're kind of nice, but all of the documentation is kind of spread around and hard to find and there's a lot of pulling up manpages and looking up words that get dropped with no context -- if you happen to know Linux security even just reasonably well and you're ever looking around for an unmet need or niche that's possible for one person to solve on their own, then this is the kind of problem that could be fixed with like one in-depth blogpost series. There's just a real need for more tutorials about this stuff that can be shared with people who want to do manual configuration or command line usage, but that don't necessarily have the background required to just jump into the Arch docs. I've thought about trying to make one, but I am very nervous about giving people bad advice since I'm mostly self-taught on a lot of the security stuff. I haven't checked back though since I started using Bubblewrap, so also maybe I'm out of date and there's more documentation today.
In Firejail: Linux namespaces and seccomp-bpf sandbox

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.