But ‘presumably’ the profiles are only going to get tighter, not looser.
Is that really different than any other package?
Further testing here reveals the software isn’t ready for prime time. Despite ‘firejail --net=eth0 -ip=10.152.152.111 qbittorrent’ no network activity was observed 2 out of 3 goes.
Hate to be a downer on my own “hey, this is out there”, but if I’m the first one to call for such containerization, there can’t be a crying need for it out there - IMO whonix resources are probably better spent elsewhere.
However, the topic of containerization, value, and heft, in a whonix context, does seem a worthy topic to keep an eye on.
Regardless of the mechanism used, e.g. docker in single application mode seems like an equally likely candidate, vs LXC full OS turnkeys - the idea of user chosen optional ‘safe app kiosk install’ seems to have merit.
If you turn the concept around, one could also see a series of ‘whonix-apps’. e.g. A whonix container installable in any system (if, e.g., a docker image), blessed as being a whonix approved anonymous (anonymizing & scrubbed/ing) turnkeyed app window.
My guess is such would be useful within qubes as well, but I expect qubes has its own equivalent mechanism already.
LXC, cgroups, ip netns, docker, vboxes, et all, seem to have come a long way. The common concepts and intents behind them seem to have many ongoing candidate implementation methodologies at various stages of development.
If I was the first to ask about firejail, … is such really all that popular a desire worthy of allocation of whonix resources?
(Says the guy that made the original request of consideration.)
need a maintainer to create such profiles since I guess it’s non-trivial work, non-negligible time effort and not free
of issues.
Profiles are really simple, so I don’t think that’s a huge burden - BUT: that makes the assumption of familiarity of containerization/LXC, etc.
I am not, so, for example, I have no idea of the pros / cons / appropriateness of the ‘seccomp’ profile directive.
In testing, I disabled a ‘noroot’ directive - aside from the LXC concepts, one would be trusting, on a per app basis, whether ‘noroot’ or not is dangerous / suitable (in a whonix context) - and for that one would have to be very familiar with the particular app, and probably its internals.
e.g. One might ask, does ‘kmail’ need ‘noroot’ not specified, or not. One might reasonably ask, why would it need root? I expect the only one who could reasonably answer such a question is one familiar with kmail internals - and there quite probably aren’t a great deal of such around. [I expect the biggest reason for noroot is apps place files in far too many unusual/unexpected places, and noroot is expedient for getting an app to run without fully understanding all the places that must be black/white-listed, exceeding the bound of the container in the process. Or at least the container being larger than it should / needs to be.] And such an app expert would be needed per app. And there are several dozen apps in there already.
One thing I noticed with my testing of ktorrent, is D-Bus use and forking apps are problematic for firejail. If whonix is by design a KDE install, and firejail is KDE broken … I came to the conclusion of hurry up and wait for further firejail maturity before looking at it any more deeply.
At least until they can demonstrate that ‘firejail --no-profile --net=eth0 {any candidate kde app}’ “just works.” (–no-profile = no restrictions, --net=eth0 = containerized network stack). i.e. To the user, ‘myapp’ and ‘firejail myapp’ should present identically without further user intervention. (Things can be made tighter, but at its loosest, it should be transparent to the user as to which way it’s running.) Seamless / transparent user use is not the case today, and it may be prudent to wait until it is.
