I’ve been trying this in the Debian-8 TemplateVM for simplicity.
I created a new AppVM off this template and FF is still not firejailed according to firejail --tree.
So, I then tried the firecfg --fix option, by:
mkdir -p /home/user/.local/share/applications
Which outputs for a bunch of programs, including FF-ESR:
/home/user/.local/share/applications/program name.desktop created
ran qvm-sync-appmenus on the templateVM
and tested FF in the AppVM.
Still not firejailed according to firejail --tree
So, the easy solution in Qubes-Whonix is to just run it from the terminal & delete all wiki steps relating to desktop links or firecfg, with that noted as ‘To Do’ in Qubes 4.0 when the .local directory population actually works. That Qubes thread suggests it is not working in 3.2
.desktop links are a MAJOR pain for Qubes. Note the difficulty we have in adding additional items for the DispVM menu, not having .local directories .desktop entries actually work for Tor Browser and Firefox-ESR. It is a block for many users, and I have seen multiple Qubes threads around this .desktop link issue. They really need to sort it out.
sudo firecfg might work for non-Qubes-Whonix, but I don’t run it, so can’t check for you. If it does work, I can update that wiki entry.
In the meantime, I’ll look at wiki entries for greener pastures (things that actually do work), like grsec templates - working here for the Debian-8 Template, plus works in combination with firejail.
Out of interest, is there any reason we can’t apply the coldhakca grsec instructions for the Debian template, and apply to the Whonix templates in Qubes? Since they are both Debian Jessie?
Or do you expect major breakage? I think somebody already had Whonix ‘grseced’ in one of those Qubes threads. That is a major security enhancement, particularly if the vanilla grsec Debian templates and grsec Whonix templates can then be used for all networking, although I believe this is currently blocked when testers have tried that for the netVM and firewallVM.