[seodisparate]

As a lightweight alternative to Docker-based (or any container-based) solutions: Try firejail. You can set up a directory that will be the "home" of the sandboxed application you're running, then you can do something like `firejail --private="${HOME}/my_firefox_jail" firefox`. There are built-in profiles for many applications already, and you can customize them (by adding `.local` files, not editing the existing `.profile` files). See the following link for details.

https://wiki.archlinux.org/title/Firejail

[kaba0]

Convenience matter. Without it being automatically on everywhere, it doesn’t protect from much. Sure it can be good for the occasional random software you trust the least, but how many exploitable bugs were found in any of your completely trustable tools?

Also, afaik firejail runs as suid, making any possible escape much more serious.

[seodisparate]

[1] discusses firejail running as root:

> For a server, the process exposed to the outside world runs as an unprivileged user (unbound or nobody). The process is started by a separate process running as root (as explained by @Ferroin above). The starting process is never exposed to outside.

> The same is true for Firejail. By the time the unprivileged server process starts, Firejail is already sleeping.

And I think Docker has a similar problem as mentioned in the "warning" section in [2]:

> Warning: Anyone added to the docker group is root equivalent because they can use the docker run --privileged command to start containers with root privileges. For more information see [3] and [4].

[1]: https://github.com/netblue30/firejail/issues/1720

[2]: https://wiki.archlinux.org/title/Docker#Installation

[goodpoint]

Actually docker is much worse due to the large attack surface.