See edited version above. I’ve tested firejailing Tor Browser in Qubes-Whonix following these steps and it all seems to work. Do you mind trying in your system to see that this is correct for you?
I’ll add your information for the working (alpha) Tor Browser sandbox in non-Qubes-Whonix shortly.
Cheers
Sandboxing Tor Browser in Non-Qubes-Whonix using the alpha Tor Project sandbox is being discussed here and I have a preliminary wiki entry based on Patrick’s success in non-Qubes-Whonix.
Patrick has confirmed these steps are correct. 
Unfortunately, Qubes-Whonix sandboxing is currently blocked by bubblewrap problems.
Looks good. Please add them to the wiki.
The onionizing sources.list wiki entry has been completed and is awaiting reviewer approval. Ditto the sandboxing wiki entry (needs your reviewer approval).
I’ll do the Firejail one next.
Damn, I was just about to update the wiki and double-checked the instructions re: firejailing Tor Browser in Qubes.
It turns out after all that firejail works okay from the terminal, but all those steps in creating a local .desktop file for Tor Browser to contain the process don’t work.
You can see it by running firejail --tree in Konsole -> it shows nothing.
Tor Browser firejailed from terminal on the other hand shows it is being run in a container.
So we have grabbed firejail, created the local directory, copied the existing desktop file over to the local directory, prefixed it with firejail, run a qvm-sync-app-menus from dom0, and it still doesn’t pick it up.
I have tried the full path to firejail in the exec line->
Exec=/usr/bin/firejail torbrowser %u
But that doesn’t work either… starts Tor Browser, but it’s not contained.
Are we sure we don’t just want to edit the existing desktop file and update it every Tor Browser release, cause this Qubes architecture is killing me 
So, I’ll just do the firejail entry with running Tor Browser from the terminal. Then, if anybody works out the .desktop links stuff later on, they can add it. Not worth the angst.
Firejail entry is awaiting reviewer sign-off. I’ve included the non-canonical method for .desktop edits, since it works (but noted it as optional steps).
Cheers
Well, if you sometimes run Firefox [or Tor Browser] without firejail while having run the same Firefox profile folder before with firejail is as good/bad as never running with firejail.
Editing /usr/share/applications/firefox-esr.desktop [or torbrowser desktop file] is a recipe for that. It will initially firejail will be used but on the next Firefox upgrades (which also happens in Debian stable during security upgrades) all desktop file changes are lost without notice. This is very easily missed. How many users will carefully look that firefox [or tb-updater] wasn’t updated and remember to reapply the modification…
[The wiki edit can stay in its non-approved form for a few hours. Very much fine. No need to delete it. In a few hours I’ll look into the desktop icon modification in home folder in Qubes and add a few edits on top, then approve.]
Problem is as of Qubes R3.2 is only parses:
/usr/local/share/applicationsIt does not parse:
/usr/local/share/applications~/.local/share/applicationsSource, a recent qubes-devel discussion:
.desktop files in /usr/local of normal AppVM?
I mentioned the firejail use case, added my thoughts to that discussion.
In meanwhile it’s either dpkg-divert in TemplateVM, which is ugly or not using any desktop files anymore, just starting it from terminal.
Why edit the desktop files? Why not use firecfg as per Dev/Firejail - Kicksecure? Could you research please if that works? Much better than desktop file edits because once firecfg symlinks are in place, no more accidental non-firejailed starts are possible.
Doesn’t work.
I’ve been trying this in the Debian-8 TemplateVM for simplicity.
sudo firecfg
Shows:
/usr/local/bin/firefox created
/usr/local/bin/firefox-esr created
/usr/local/bin/iceweasel created
/usr/local/bin/icedove created
/usr/local/bin/evince created
/usr/local/bin/ssh created
/usr/local/bin/keepassx created
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
firecfg --fix
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.
It probably doesn’t work since /usr/local of TemplateVM is not shared with TemplateBased AppVM which has its private /usr/local.
It might work if this sudo firecfg gets run in every individual TemplateBased AppVM. But that’s not a great solution.
For something like filezilla.desktop it might work since it uses Exec=filezilla. (Then the wrapper in /usr/local would perhaps be preferred.)
For other applications using the full path however such as firefox-esr.desktop which uses Exec=/usr/lib/firefox-esr/firefox-esr %u this wouldn’t work. No way an /usr/local wrapper could sneak in firejail then.
Right, with all these half baked solutions it’s probably best to recommend starting applications from the command line.
Yes, that that won’t work due to Qubes desktop files parsing limitations.
Yes. Certainly not working in R3.2 as per that thread.
I don’t see why this wouldn’t work.
Thanks re: signoff on Firejail.
The grsec wiki entry for Qubes-Whonix (Debian 8 TemplateVM) is awaiting reviewer sign-off here:
The entries for Whonix and Fedora templates, and dom0 and dispVMs with grsec will be done once coldhak has finished them.
Dumb question: the external website image links don’t appear in the wiki entry? How do we upload our own snapshots (if that is required) in mediawiki?
I’ll try firecfg in the appVM and let you know. I’ll also try grsec in the Whonix templates, but I suspect it won’t work right, because Coldhak has that on their ‘to do’ list on github. But you never know.
[quote=“torjunkie, post:63, topic:3221”]
the external website image links don’t appear in the wiki entry?[/quote]
That’s a security feature.
When you edit a page, above the text editor field there should be Drop files here area.
Also there is Tools -> Upload file.
Or direct link:
Login required - Whonix
You need a wiki account and upload rights however.
Licensing:
For legal reasons, to avoid lawsuits and legal vulnerabilities… Any image uploaded must comply with copyright. Must be compatible with GPL v3 or any later. Must not violate the authors rights to the file. Very good is public domain stuff. However, Libre Software licenses that require attribution work also - we just need to provide the proper attribution. Ideally on the wiki page of the file (image) we have a link the original as well as a snapshot (archive.org, webcitation.org) as proof that by the time we got that file was under a certain license.
Now we have the Qubes mirrors on the Whonix onion, I assume this information below is okay to add to the “Onionizing Repositories” entry?
I was confused between the options that are now available:
a) http://qubes-mirror.kkkkkkkkkk63ava6.onion
b) qubes-deb.kkkkkkkkkk63ava6.onion
c) qubes-yum.kkkkkkkkkk63ava6.onion
But, I have tested with option (b) above and it works nicely in the Debian and Whonix templates. Please confirm I am okay to add this to the wiki though. The top level mirror (a) doesn’t work for whatever reason.
This now means if you use Debian-8 as the net and firewall VMs - recommended, since FedoraSoft wants to ‘phone home’ on a regular basis as discovered by entr0py - there is no need to expose anything you are installing/updating outside the Tor network.
###Onionizing Qubes Sources
Debian-8 Template VM:
(1) Open a terminal and edit sources.list with editor rights:
sudo nano /etc/apt/sources.list.d/qubes-r3.list
(2) Change as follows:
# Main qubes updates repository
deb http://qubes-deb.kkkkkkkkkk63ava6.onion/r3.2/vm jessie main
#deb [arch=amd64] http://deb.qubes-os.org/r3.2/vm jessie main
#deb-src http://deb.qubes-os.org/r3.2/vm jessie main
Save and exit.
Check it is working:
sudo apt-get upate
You shouldn’t see any output without a .onion extension.
Whonix-Gateway and Whonix-Workstation Template VMs
(1) Open a terminal and edit sources.list with editor rights:
sudo nano /etc/apt/sources.list.d/qubes-r3.list
(2) Change as follows:
# Main qubes updates repository
deb http://qubes-deb.kkkkkkkkkk63ava6.onion/r3.2/vm jessie main
#deb [arch=amd64] http://deb.qubes-os.org/r3.2/vm jessie main
#deb-src http://deb.qubes-os.org/r3.2/vm jessie main
Save and exit.
Check it is working:
sudo apt-get update
You shouldn’t see any output without a .onion extension.
It’s working on my end. It’s just a mirror of the top-level ftp.qubes-os.org (without distfiles/).
So, [arch=amd64] should be removed? Out of curiosity, why is that?
Note that I asked a similar question here. I’m really curious: If substituting the .onion URLs is sufficient, then what’s the point of apt-transport-tor? If it’s not needed, why does it even exist?
Hi Andrew,
I had removed the [arch=amd64] bit by mistake. I suppose that’s a big no-no, but I’m not sure of the implications, since I’ve barely researched the repositories stuff. That’s why I was checking in first with the Whonix team, as I don’t want to suggest something unsafe.
Do you now have:
deb [arch=amd64] http://qubes-mirror.kkkkkkkkkk63ava6.onion/r3.2/vm jessie main
in your sources file working well? If so, I’ll change the suggested wiki entry to reflect this.
From memory, tor:// or tor:// + http:// would lead to tor over tor scenarios in Whonix. @entr0py understands why, but I’m not very technical I’m afraid Something about apt being “uwt-wrapped” in Whonix already.
PS Love your work over at Qubes. Very nice documentation and explanations provided to all and sundry.
could you please request that the hidden service mirrors move under the new qubes hidden service as that would be more appropriate and less confusing (as yum.qubesos4rrrrz6n4.onion and deb.qubesos4rrrrz6n4.onion and maybe ftp.qubesos4rrrrz6n4.onion)
re [arch=amd64]:
Thanks to Andrew, ononizing the Qubes repos is now documented here (I’ll add to Whonix wiki “onionizing repositories” section if that’s okay with you Patrick):
https://www.qubes-os.org/doc/hidden-service-repos/
###Hidden Service Repos
Run the following commands in dom0 in order to use Qubes’ Tor hidden service repos for each type of VM.
Note: The cats are optional, for confirmation only.
Dom0
sudo sed -i ‘s/yum.qubes-os.org/qubes-yum.kkkkkkkkkk63ava6.onion/’ /etc/yum.repos.d/qubes-dom0.repo && cat /etc/yum.repos.d/qubes-dom0.repo
sudo sed -i ‘s/yum.qubes-os.org/qubes-yum.kkkkkkkkkk63ava6.onion/’ /etc/yum.repos.d/qubes-templates.repo && cat /etc/yum.repos.d/qubes-templates.repo
Fedora
qvm-run -a --nogui -p -u root $FedoraTemplateVM ‘sed -i “s/yum.qubes-os.org/qubes-yum.kkkkkkkkkk63ava6.onion/” /etc/yum.repos.d/qubes-r3.repo && cat /etc/yum.repos.d/qubes-r3.repo’
Debian and Whonix
qvm-run -a --nogui -p -u root $DebianTemplateVM ‘sed -i “s/deb.qubes-os.org/qubes-deb.kkkkkkkkkk63ava6.onion/” /etc/apt/sources.list.d/qubes-r3.list && cat /etc/apt/sources.list.d/qubes-r3.list’
Thanks to @fortasse for setting all the repos up on the .onion!
Re: why it’s not on a qubes’ onion address, I’m not sure - you’d have to check out the qubes issues and forums. I think it was something to do with Whonix having the space, and the original .onion slated for Qubes repos was not able to be used for some reason (no private key?)
Now it’s set up, I don’t think they are going to make this a priority i.e. qubesosXXXXXXXX.onion for repos.