Hardening Qubes-Whonix

[adw]

The qvm-backup key derivation/management (backup encryption) is reported to be insecure.

“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.)

Thus, until this issue is sorted in Qubes 4.0, Qubes-Whonix users should probably use the following work-around for hardening purposes:

• Store Qubes-encrypted backups on a separate back-up disk that is already encrypted with LUKS

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.

[torjunkie]

Noted.

The recommendation could instead read:

• 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.

[torjunkie]

@entr0py

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).

What have I missed?

[entr0py]

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?

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

I’m a little confused which ones we are pointing to and whether it is just tor:// or tor + http://

Just http. Because apt-get is uwt-wrapped and gets sent straight to the Gateway. No apt-transport-tor.

[Patrick]

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);

Just now created:
https://www.whonix.org/wiki/Tor_Browser#Tor_Browser_Sandboxed

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);

That belongs to https://www.whonix.org/wiki/Grsecurity. Do these instructions work in KVM? If so, the existing page becomes chapter KVM. //cc @HulaHoop

[torjunkie]

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:

kdesudo kwrite /etc/apt/sources.list.d/debian.list

If you are using a terminal-only Whonix, run:

sudo nano /etc/apt/sources.list.d/debian.list

(2) Cut and paste the following .onion mirrors and comment out (#) the corresponding http repositories noted in bold:

#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

(3) Save the new debian.list file

(4) Point to the Whonix APT Repository .onion mirror:

sudo whonix_repository --baseuri http://deb.kkkkkkkkkk63ava6.onion --enable --repository stable

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:

kdesudo kwrite /etc/apt/sources.list.d/torproject.list

If you are using a terminal-only Whonix, run:

sudo nano /etc/apt/sources.list.d/torproject.list

Cut and paste the following text and comment out (#) the corresponding http repository noted in bold::

#deb http://deb.torproject.org/torproject.org jessie main
deb http://sdscoq7snqtznauu.onion/torproject.org jessie main

Save and exit.

Footnotes:

[1] https://www.whonix.org/wiki/Whonix-APT-Repository#Repository_Location_URI
[2] Whonix 14 will prefer .onion repositories by default, even when adding third-party resources
[3] Onionizing Qubes-Whonix Repositories
[4] https://www.whonix.org/wiki/Install_Software#How_to_install_or_update_with_most_caution.3F
[5] https://blog.torproject.org/blog/tor-heart-apt-transport-tor-and-debian-onions
[6] tor:// or tor:// + http:// entries are not required in Whonix because apt is uwt-wrapped.
[7] https://www.whonix.org/wiki/Whonix-APT-Repository#Whonix_APT_Repository_Overview
[8] Qubes users can repeat these steps in their Debian-8 TemplateVM to onionize installations and updates.

[Patrick]

torjunkie:

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?

The canonical way is:

sudo whonix_repository --baseuri http://deb.kkkkkkkkkk63ava6.onion --enable --repository stable

Won’t ever be automatically overwritten.

[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.]

[entr0py]

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

Wow, really sloppy. Sorry.

deb http://deb.kkkkkkkkkk63ava6.onion jessie main vs
deb http://kkkkkkkkkk63ava6.onion jessie main

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?

Whonix 14 ticket: https://phabricator.whonix.org/T399

---

@entr0py please check this is okay.

Looks good to me. Thanks!

[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.

(2) Edit the Debian sources file:

[6] 'Credit to entr0py for this information.

[6] Debian starts Onionizing

Community effort. Better to link to discussions I think - unless attributing to a well-known expert. [Plus I don’t want any blame.]

[Patrick]

[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.]

Here is a list of all templates (since we have not categorized them):
https://www.whonix.org/wiki/Special:UncategorizedTemplates

(You can find such special pages through https://www.whonix.org/wiki/Special:SpecialPages.)

If you like to create any new templates, please just tell me the template page names and I create them.

[Patrick]

Qubes-Whonix users can achieve significant hardening of their system by completing a number of additional steps after installation of the base system.

(Many are general, non-Qubes specific.)

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:

I like the ordering in various difficulties.

https://www.whonix.org/wiki/Security_Guide is supposed to contain only items being ‘easy’ and perhaps ‘medium’.

https://www.whonix.org/wiki/Advanced_Security_Guide is supposed to contain only ‘difficult’ items.

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.]

[torjunkie]

Thanks!

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.

[entr0py]

does the Tor project .onion mirror belong in the Debian sources file?

No, if anything, it should get its own torproject.list. I would leave it out of the end-user security guide. Only for testers or paranoid. Testers Wanted! Tor - Stable Upgrades

[HulaHoop]

They do but can just as easily work for other hypervisors by changing a single config option.

[Patrick]

For Qubes [Xen] it’s not as simple. ( https://github.com/coldhakca/coldkernel/issues/35 )

Doesn’t work out of the box for VirtualBox either. (Breaks X, guest additions and apparmor.)

So I wonder it works with KVM at all.

[Patrick]

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.]

[HulaHoop]

Doesn’t work out of the box for VirtualBox either.

VBox is an out of tree module and things with dkms are very flaky.

So I wonder it works with KVM at all.

Working here but thats not much consolation and I won’t pretend to know whats wrong in Xen’s case.

[torjunkie]

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.

[Patrick]

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).

Has been (partially*) discussed here:
https://forums.whonix.org/t/firejail-seccomp-more-options-for-program-containment

(* I’d have to re-read first to know.)

[torjunkie]

Hi

According to this: https://www.whonix.org/wiki/Dev/Firejail

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.

[Patrick]

torjunkie:

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

Exec=firejail /usr/lib/firefox-esr/firefox-esr %u

Maybe full path to firejail is required as well.