X-Git-Url: https://git.ralfj.de/web.git/blobdiff_plain/43307ef533738f9b108a6daa91541692f396a725..fac47c7e7858bb53393bb1bcbe30e5b64509d250:/personal/_posts/2024-04-14-bubblebox.md?ds=inline diff --git a/personal/_posts/2024-04-14-bubblebox.md b/personal/_posts/2024-04-14-bubblebox.md index 85dc684..56a23a6 100644 --- a/personal/_posts/2024-04-14-bubblebox.md +++ b/personal/_posts/2024-04-14-bubblebox.md @@ -33,12 +33,16 @@ org.freedesktop.Flatpak=none org.freedesktop.secrets=none ``` +I also use [Flatseal], an amazing application that helps to check which permissions applications get, and change them if necessary. + +[Flatseal]: https://flathub.org/apps/com.github.tchx84.Flatseal + ## BubbleBox However, not all software exists as Flatpak. Also, sometimes I want software to run basically on my host system (i.e., to use the regular `/usr`), just without access to literally *everything* in my home directory. Examples of this are Factorio and VSCodium. -The latter doesn't work in Flatpak as I want to use it with LaTeX, and realistically this means it needs to run the LaTeX on my host. +The latter doesn't work in Flatpak as I want to use it with LaTeX, and realistically this means it needs to run the LaTeX installed via `apt`. The official recommendation is to effectively disable the Flatpak sandbox, but that entirely defeats the point, so I went looking for alternatives. [bubblewrap] provides a very convenient solution: it can start an application in its own private filesystem namespace with full control over which part of the host file system is accessible from inside the sandbox. @@ -46,15 +50,18 @@ I wrote a small wrapper around bubblewrap to make this configuration a bit more this project is called [BubbleBox]. This week-end I finally got around to adding support for [xdg-dbus-proxy] so that sandboxed applications can now access particular D-Bus functions without having access to the entire bus (which is in general not safe to expose to a sandboxed application). That means it's finally time to blog about this project, so here we go -- if you are interested, check out [BubbleBox]; -the project page explains how you can use it to set up your own sandboxing. -One day I should probably rewrite this in Rust... +the project page explains how you can use it to set up your own sandboxing.[^1] + +[^1]: One day I should probably rewrite this in Rust... maybe this will be my test project for when [cargo-script](https://rust-lang.github.io/rfcs/3424-cargo-script.html) becomes available. I should also note that this is not the only bubblewrap-based sandboxing solution. [bubblejail] is fairly similar but provides a configuration GUI and a good set of default provides; it was a very useful resource when figuring out the right bubblewrap flags to make complex GUI applications work properly. (Incidentally, "bubblejail" is also how I called my own script originally, but then I realized that the name is already taken.) Joachim Breitner also recently [blogged](https://www.joachim-breitner.de/blog/812-Convenient_sandboxed_development_environment) about his own bubblewrap-based sandboxing script. -There are many ways to do this, and it was fun to figure out my own solution. +sloonz has a similar [script](https://gist.github.com/sloonz/4b7f5f575a96b6fe338534dbc2480a5d) as well, with a nice yaml-based configuration format and [great explanations](https://sloonz.github.io/posts/sandboxing-1/) for what all the flags exactly do. +Had their script existed when I started what eventually became BubbleBox, I would have used it as a starting point. +But it was also fun to figure out my own solution. Using bubblewrap and xdg-dbus-proxy for this was an absolute joy. Both of these components came out of the Flatpak project, but the authors realized that they could be independently useful,