Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker → bubblewrap #95

Closed
DemiMarie opened this issue Nov 5, 2020 · 4 comments
Closed

Docker → bubblewrap #95

DemiMarie opened this issue Nov 5, 2020 · 4 comments
Labels
enhancement New feature or request

Comments

@DemiMarie
Copy link

https://github.com/containers/bubblewrap is an unprivileged sandboxing tool for Linux. It has several advantages over Docker and Podman:

  • It is much smaller and simpler, with less attack surface.
  • Unlike Docker, it does not require root-equivalent privileges.
  • It is designed to safely run be setuid root, so (unlike Podman) it works even when unprivileged user namespaces are disabled.
  • It is often installed by default, as it is used by GNOME to sandbox thumbnailers.

Bubblewrap does not come with a seccomp filter, but it allows the user to provide one. We could provide one that is far more restrictive than that used by the default Docker configuration.

@anarcat anarcat mentioned this issue Apr 12, 2021
@anarcat
Copy link

anarcat commented Apr 12, 2021

this seems like a duplicate of #95, in a way: flatpak uses bbwrap for sandboxing, and might serve as a better distribution mechanism than "just use bbwrap" directly...

@DemiMarie
Copy link
Author

this seems like a duplicate of #95, in a way: flatpak uses bbwrap for sandboxing, and might serve as a better distribution mechanism than "just use bbwrap" directly...

Yes and no. Flatpak does use bubblewrap under the hood, but not everyone will use Flatpak, so we should still have a fallback.

@micahflee
Copy link
Contributor

I've started looking into this a little as an option for Linux, while keeping Windows and Mac using Docker. I really like the idea but here are the roadblocks I'm seeing.

I'll want it to run the dangerzone OCI that's hosted here so that all versions of Dangerzone can use the same container image, and if I add features (e.g. allow new file types) I can add the feature to just one place: https://hub.docker.com/r/flmcode/dangerzone

Another benefit to using a container image is that I don't have to worry about the host OS that's using Dangerzone. If you're in an old version of Debian, a new version of Ubuntu, Fedora, etc., the container image can have all the same dependencies.

By itself, bubblewrap just lets you run code in a new empty sandbox but doesn't have support for OCI image. There's a project called bwrap-oci that adds support for this. Unfortunately, bwrap-oci is only packaged in Fedora, not in Debian, Ubuntu, or other distros, which means using it as a dependency for non-Fedora distros is difficult.

The bwrap-oci project is part of the fedora Project Atomic, and its website projectatomic.io seems dead. I was able to find an archived version of a blog post describing bwrap-oci though: https://web.archive.org/web/20190701092127/http://www.projectatomic.io/blog/2017/07/unprivileged-containers-with-bwrap-oci-and-bubblewrap/

So overall, there are various hurdles in the way of Dangerzone using bubblewrap. I think a much simpler way to go for now would be switching from docker to podman for Linux, especially now that podman is packaged in Debian bullseye and newer and in Ubuntu 20.10 and newer.

@micahflee
Copy link
Contributor

For now I'm going to close this aspirational bubblewrap issue in favor of switching to Podman: #120

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants