bubblewrap VS Flatseal

Nothing nix specific but you may be interested in https://github.com/containers/bubblewrap

Recently, I came across Chainguard and wrote the article How to build Docker Images with Melange and Apko. As a fervent supporter of Kubernetes and GitLab CI, I was eager to experiment with building images using Melange in this particular setup. GitLab's shared Runners work seamlessly with Bubblewrap, eliminating the need for additional configurations. This post is intended for enthusiasts like myself, interested in hosting their own Kubernetes Runners and leveraging the Kubernetes Runner Type of Melange.

```

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 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.

And not only that, the idea of portals is, IMO, misguided. See this view/bugreport when a flatseal user understands that even though they restricted permissions to access a certain area, the flatpak, itself, can ask to open files there and if OK'd that will be allowed. Their expectation is that with the overrides say "no access" it means "no access even if the flatpak asks very nicely". https://github.com/tchx84/Flatseal/issues/196

Since you installed the programme via Flatpak, you should simply lack the necessary rights (https://docs.flatpak.org/en/latest/sandbox-permissions.html). You can extend the rights quite easily with https://github.com/tchx84/flatseal.

Yes, filed https://github.com/tchx84/Flatseal/issues/196 a while ago, got no joy.

One design feature than can turn into an issue in some scenarios (usually dev tools) is the permissions of a flatpak. In case I need to tweak things, I use Flatseal. I know you can manually do this from the command line but I don’t change permissions that often so I don’t bother learning how to do that.

Does the Flatpak Permissions Settings replace a tool like Flatseal?

What about flatseal then ? https://github.com/tchx84/Flatseal

https://github.com/tchx84/Flatseal (Also on Discover. For security reasons, the Discover store installs apps as sandboxed "flatpak" apps. This one is used to view what each up can do and change the permissions of apps. May be required if the sandboxing breaks something, though usually not required.)

I believe it does. As an example if I try running Godot from the Steam flatpak, it won't be able to see any of the contents of my ~/Projects folder unless I explicitly allow the steam flatpak access to that directory that via flatpak's CLI options or using Flatseal