firejail VS namespaced-openvpn

bubblewrap is designed as a low-level too. There is nothing quick and dirty about it. It disallows everything by default and you have to be explicit about what you want to share with the host. If your application needs complex permissions/resources, then you will need to have a complex bubblewrap command line.

Once you have figured out which permissions/resources you need for a given program, you can wrap the command line invocation in a shell script.

If you want other people to do the work of defining permissions/resources, then have a look at firejail: https://github.com/netblue30/firejail

Firejail is cool: https://github.com/netblue30/firejail

Linux namespaces/cgroups but nowhere near as heavy as Docker.

I use it when I want to limit the memory of a Python script:

```

Firejail can also be a useful option, though no good if you're on Mac https://firejail.wordpress.com/

Uses the same Linux primitives as docker etc, but can be a bit more ergonomic for this use case

Firejail, Flatpak (which uses Bubblewrap under the hood), and Snap (which uses AppArmor) all use the same underlying technology: Linux namespaces.

This question comes up a lot, and has been answered here: https://github.com/netblue30/firejail/wiki/Frequently-Asked-...

TL;DR: Firejail has much more comprehensive features than Flatpak (Bubblewrap). Firejail also has more comprehensive network support, support for AppArmor and SELinux, and easier seccomp filtering.

Compared to Snap (which uses AppArmor), Firejail is compatible with AppArmor and again goes above and beyond with a lot of additional features.

Wonderful little tool, too bad you must chain various exec calling tools to get cgroups (a bit akin to `ionice ... nice ... cmd`) and Linux users namespaces can't allow UNIX sockets while preventing network access (I think?).

Migrated from Firejail when its complexity annoyed me too much and I hit https://github.com/netblue30/firejail/issues/3001 (Firejail doesn't like parens or brackets in --put/--get parameters) to a badly NIH version using bwrap and bash to have "profiles":

Firejail does this. The profile database is the two "profile" directories in https://github.com/netblue30/firejail/tree/master/etc

What do you mean by a Firefox container? Do you mean FireJail?

Network namespaces are a really nice feature for me. I use them for a few things. They are a simple and foolproof way of running programs in VPNs without having the whole system use the VPN, and you can have multiple of them, and even chain/nest them (foolproof as long as you remember to run it in the network namespace, such as a wrapper script or systemd service). WireGuard remembers the namespace it was created in and uses it for connecting to the VPN endpoint, so if you create it in your init namespace, then move it to a different namespace, programs in that different namespace can use the WireGuard interface which connects to the VPN endpoint using the original connection. Programs have no direct access to the internet if the VPN interface disappears. (https://www.wireguard.com/netns/#ordinary-containerization). There is also https://github.com/slingamn/namespaced-openvpn for OpenVPN.

namespaced-openvpn can do this.

Even found namespaced-openvpn, a ready-made solution for this problem.

It would depend of your device but on linux you can use namespaced-openvpn (https://github.com/slingamn/namespaced-openvpn). It would let you connect to vpn1 and running vpn2 over vpn1 for example.

There are ready-made solutions like namespaced-openvpn for OpenVPN. See #27 when using with libtorrent-rasterbar. For WireGuard, you can read up on https://www.wireguard.com/netns but it might be a bit confusing. I've easily made my own script which implements this so that it creates a network namespace, creates a WG interface, moves the WG interface into the new network namespace, then configures the WG interface (which is now in the new network namespace).

If you don't feel like using docker, this is an awesome script to seamlessly launch OpenVPN and spawn a new network namespace with only the tun interface in it. Handy af.