Did you test https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/RelativeLink/start-tor-browser and it worked? If so, I would set the state of https://trac.torproject.org/projects/tor/ticket/19055 to needs_review. (Could still take a long time until review and merge but anyhow.)
Of course tb-starter could autodetect when start-tor-browser could native firejail support and then skip tb-starter firejail therefore (grepping start-tor-browser), but things would get more and more complex and obscure.
This is probably the way to go because once its done you can forget about it.
I hope this is right. I foresee this could be causing issues in future. (Would happen if the grep breaks in case they change their implementation in which script they add firejail.)
I'd say it to https://github.com/Whonix/apparmor-profile-torbrowser. (The clean way would be to rename the packatge to containment-profile-torbrowser but let's skip this overhead.)
Without a custom package we won't be able to ship custom profiles for programs that don't necessarily have apparmor profiles
In that case we create a new package, containment-profiles-xxx.
but I prefer all profiles to upstream anyway rather than maintaining our own. I don't think we will use Firejail to isolate Whonix specific daemons like sdwdate or cpfp (because systemd supports similar properties).
Its very unlikely that Debian will allow something like a firecfg post-install script to enable symlinks by default. It will be considered "intrusive" because it will do unexpected changes to other unrelated packages in a general purpose distro.
One day they will also enable AppArmor by default once AppArmor was installed. As per upstream feature request:
Please automatically enable AppArmor when the userspace tools are installed
I don't think it will be different for firejail.
I want as little Whonix specific modifications to general stuff without having raised it upstream.
A better option - a simple script that runs once at build time to activate firecfg is enough
Not enough. Doesn't work for users who upgrade. Then there will be discussions about the differences of new builds vs upgraded builds. I want to keep the number of such discrepancies as low as possible. Every issue will get raised over and over and over again it all sucks up recourses. Piles up. Until a point, where the project becomes unmanageable.
Probably also does not work for software that has profiles but where the package gets installed by the user after firejail was installed. I speculate for reasons of cleanness, it will not be creating symlinks for binaries that are not yet installed in preparation that it may one day be installed.
The only clean way to implement this is a dpkg trigger. Run firecfg - if some option is set in a
.d config filder - each time something is installed to
/sbin or perhaps best even
/ (therefore running it every time during apt-get). Otherwise it will always be inconsistent whether an installed firejail, and profile, and to be contained binary is installed at the same time will result in using firejail. That working for some users but not for all. Such things are horrible.
I can implement this dpkg trigger into the security-misc package, but raising this upstream beforehand is very much desired by me. Because whenever someone criticizes why it is done in Whonix and not a general thing, I can just reply with an ideally valid and irrefutable reasoning by posting a single link. So when I will forget about this, I don't have to spend time again on making going through the thought process and making the argument again.