“Insecure” is not quite accurate. The problem (as partially described by the quotation) is that we rely on OpenSSL’s encryption function, which uses a weak key derivation scheme (basically just a single round of md5). The backup system is secure as long as you use a high-entropy passphrase. Since you should be doing so anyway, this issue isn’t something that should necessary stop you from using qvm-backup. (I’m the one who originally reported this issue, and I’ve continued to use it without interruption.)
Yes, this is a good idea and won’t hurt. (I was doing this even before finding out about the weak key derivation scheme issue.) The only problem is that it doesn’t really work for offsite-backups.
Qubes users must have a sufficiently long (high-entropy) passphrase to store encrypted back-ups due to OpenSSL’s weak key derivation scheme, which relies on a single round of md5. Failing this, another solution is to store encrypted backups on a separate back-up disk that is already encrypted with LUKS.
Do you mind cutting and pasting your sources.list (.onions) which works, so that I can edit the wiki somewhere to reflect the correct sources for those wishing to harden their Qubes-Whonix installation?
I’m a little confused which ones we are pointing to and whether it is just tor:// or tor + http:// - what else is new
Reflecting on what we have covered so far, a future wiki entry might look something like that below (with links to relevant wiki entries/stubs). It is better to have it in one place, so users have a quick reference and don’t have to search everywhere for this information:
Qubes-Whonix users can achieve significant hardening of their system by completing a number of additional steps after installation of the base system.
Successful completion of these steps below is dependent upon the user’s skill level and available hardware. Applicable steps are marked with ‘easy’, ‘medium’ or ‘difficult’ tags to reflect this:
Default the Debian mirrors in sources.list to available .onions (easy);
Install all available apparmor profiles in the Whonix-Workstation and Whonix-Gateway TemplateVMs (easy);
Enable seccomp in the Whonix-Gateway TemplateVM torrc file (easy);
Use the hardened (alpha) Tor Browser series to resist fingerprinting and have additional memory protections (easy);
Use the (alpha) Tor process sandbox to restrict exploitation opportunities (difficult - not yet implemented in Whonix; requires sandbox compilation - @Patrick, this requires a wiki stub somewhere);
Implement MAC spoofing for ethernet and/or wi-fi via Qubes user documentation (medium);
Use all instances of the Whonix-Workstation in a Whonix-Workstation DisposableVM - preferably uncustomized to resist fingerprinting (medium);
Implement GRSEC templates for Fedora, Debian and Whonix templates in the Qubes system (difficult; only Debian currently available - @Patrick, we need a GrSec stub somewhere in the wiki for future copying of all steps);
Tweak the Tor Browser to provide ClearClick protections, run the security slider in the highest position, restrict Javascript uniformly, and default to .onion searches via DuckDuckGo (easy);
Store all login credentials and passwords in an offline vault VM (preferably in a password manager), and cut and and paste into the Tor Browser when required (easy);
Never type directly into the Tor Browser to resist typing profiling (easy);
Install newer Tor versions via Whonix config settings i.e. jessie-proposed-updates (easy);
Install latest versions of the Linux kernel available to benefit from mainlined kernel hardening (easy);
Use AEM (anti-evil-maid) in Qubes, in combination with a Trusted Platform Module (medium);
Store encrypted Qubes backups with a sufficiently long (high-entropy) passphrase due to OpenSSL’s weak key derivation scheme, which relies on a single round of md5 or store encrypted backups on a separate back-up disk that is already encrypted with LUKS (easy);
Install Qubes-Whonix with a sys-usb template to provide protection from malicious compromise of dom0. This requires available USB controllers and, in a desktop configuration, available PS/2 ports and adapters for the keyboard and mouse (medium).
These are non-Qubes-Whonix specific so would be good if others could see them too.
#### Debian onion mirrors
# deb http://ftp.debian.org/debian jessie main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie main contrib non-free
# deb http://security.debian.org jessie/updates main contrib non-free
deb http://sgvtcaew4bxjd7ln.onion jessie/updates main contrib non-free
# (optional - Backports)
# deb http://ftp.debian.org/debian jessie-backports main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie-backports main contrib non-free
#### Whonix onion mirrors
# deb http://deb.whonix.org jessie main
deb http://deb.kkkkkkkkkk63ava6.onion jessie main
#### Tor Project mirrors
# (optional - for direct Tor package)
# deb http://deb.torproject.org/torproject.org jessie main
deb http://sdscoq7snqtznauu.onion/torproject.org jessie main
#### Qubes - still waiting
deb [arch=amd64] http://deb.qubes-os.org/r3.1/vm jessie main
Just http. Because apt-get is uwt-wrapped and gets sent straight to the Gateway. No apt-transport-tor.
Suggested entry below (Security Guide section) for the benefit of both Qubes and Non-Qubes-Whonix users. Tested and now working on my system for both templates.
Onionizing Whonix and Debian Repositories
When Whonix, Debian and Qubes packages are installed or updated, default settings point to repositories with a http:// URI.[1][2] However, experimental .onion support is already available for both Whonix and Debian packages, with Qubes .onion mirrors planned for the near-term.[3][4]
In order to install or update with the utmost caution, users may consider manually editing their sources.list to point to the Whonix and Debian .onion mirrors. There are several security and privacy benefits of this approach:[5]
The user cannot be uniquely targeted for malicious updates (attackers are forced to attack everyone requesting the update);
The package repository, or observers watching it, can’t track what programs you’ve installed;
The ISP cannot easily learn what packages you fetch; and
End-to-end authentification and encryption provides protection against man-in-the-middle attacks e.g. version downgrade attacks.
To use the .onion mirrors, it is necessary to change the whonix.list and debian.list files in the /etc/apt/sources.list.d directory in both the Whonix-Workstation and Whonix-Gateway TemplateVMs.[6]
(1) In the TemplateVM, open the Debian sources file in an editor with root rights.
If you are using a graphical Whonix or Qubes-Whonix, run:
Note: Users have four preferences available for Whonix packages: stable, stable-proposed-updates, testers and developers. Change the entry above to reflect this preference.[7]
(5) Check the .onions are correct and functional in your Whonix system:
sudo apt-get update && sudo apt-get dist-upgrade
Remember to repeat steps 1-5 for both the Whonix-Workstation and Whonix-Gateway TemplateVMs.[8]
(6) OPTIONAL testers/paranoid users step - create an onionized torproject.list:
If you are using a graphical Whonix or Qubes-Whonix, run:
Tested on my system. Working, except for a 404 error on the Whonix server:
Failed to fetch http://kkkkkkkkkk63ava6.onion/dists/jessie/main/binary-amd64/Packages 404 Not Found
I think we can also add these .onions entries to a new user.list, instead of manually changing the debian.list and whonix.list so i.e so they are not later written over by packages updates?
[With a small exception, if the onion ever changes (upcoming strong
hidden services keys) we’ll sed replace the old to the new onion
trough whonix-legacy package.]
[I need a wiki for the wiki. I know there are templates for #1 and #2 that generalize instructions for qubes-whonix & non-qubes-whonix. I don’t know where to find them though.]
(1) In the TemplateVM, open a terminal with Konsole.
Perhaps Security_Guide needs a face lift? Perhaps remove all non-actionable items? I.t. remove all items that are just knowledge. Move that elsewhere, to where? And then have only ‘easy’ and ‘medium’ difficult actionable items on that page? [Plus links to other actionable items that have a separate page such as grsecurity.]
Works with entr0py’s amended .onion mirror link, as does the canonical method for enabling the Whonix repository. @entr0py does the Tor project .onion mirror belong in the Debian sources file?
See edits above. If this is okay, I will insert it in the security guide somewhere.
Patrick - I agree re: security docs. If entr0py and Ego have the quick-start guide in hand, then I hope to take this on as a mini-project. It is one of the most important sections of the wiki.
My other main interests are getting the Tor sandboxing stuff working (when you have the time) and helping to test and document this, and seeing that GRSEC documentation and testing works in Qubes-Whonix. Most of this will hopefully just be cut and pasting from coldhacka’s blog with the appropriate attribution.
Another point to add… Due to https://forums.whonix.org/t/disable-sys-net-pings-to-fedoraproject-org switch your sys-net and sys-firewall to Debian, if that works for you. [medium difficulty since this can break your networking. I advice to keep the original sys-net and sys-firewall Fedora based. Just in case. So you can switch back. And have a separate sys-net-debian as well as sys-firewall-debian.]
Good call. I have tested this and it works (Debian sys-net and firewall).
The side benefit is you can defer to .onions also in the debian-8 templateVM, meaning the whole system is onionized, except for Qubes mirrors currently (with the .onion project underway).
I realize another addition to the list is putting any clear-net browsing (Firefox in Debian AppVM) in a firejail sandbox. Firejail is available from Jessie backports and seems to work well.
The only question is (I know you have a huge firejail thread going on elsewhere), how does one edit the qubes desktop file to run not just plain FF, but the command “firejail firefox” in the executable line? I have located the .desktop file, but wasn’t sure. Is some kind of symbolic link required or “” somewhere? Just throwing in “firejail firefox” there doesn’t work.
re Qubes dom0 desktop files edit for firejail support:
Don’t. Really. Unless of course there is really no other way around. dom0 should not be involved at all. That should be purely up to the VM templates. Qubes dom0 start menu is capable to extract the full exec line. For example whonix-irc-chat-support.desktop uses hexchat --url ircs://irc.oftc.net:9999/#Whonix. The only place where this is configured is inside the template.
The question is: “How to firejailify an application without requiring the user manually typing firejail into the console.”
Or a wider question: "How to automatically prepend commands (such as firejail before applications (such as firefox).
A short term workaround until the proposed upstreaming of start-tor-browser [4] happens: is to append Firejail to all launcher commands under: /usr/share/applications. Reasoning: TBB folder not visible to users. For a user to accidentally execute Tor Browser without protection, they have to go out of their way to find and launch the start-tor-browser script in the hidden TBB folder. In TBB’s use-model we don’t have to worry about command line users because TBB is a GUI app first and foremost. Visual indicators further help warn against accidental execution in the unlikely event it happens. If they use command line the might as well put Firejail before the script name. This solution is tested and working and survives TBB upgrades.
So, I imagined this would mean:
1) In Qubes-Whonix, we would edit the relevant file in the Debian-8 TemplateVM
/usr/share/applications/firefox-esr.desktop
2) Prepend the firefox executable in the following line with “firejail”
Exec=/usr/lib/firefox-esr/firefox-esr %u
→
Exec=/usr/lib/firefox-esr/firejail firefox-esr %u
And hoping for Christmas magic, it would lead to Firefox automatically starting contained, because the Qubes menu entry points to: /usr/share/applications/firefox-esr.desktop
Of course, not that easy. Help?
I’m trying to make this easy for dumb users like me. We need our hands held every step of the way, or we will do something really stupid
Although, I don’t mind running a terminal with “firejail firefox” every time, there must be an easy solution.
Really.