Long Wiki Edits Thread

For the most part I finished the steps and language but I ran into a little hiccup and could use some guidance.

Whonix 13 and Whonix 14 torrc files are not similar in apperance. However the torrc files can be copied across: Whonix 13 → Whonix 14 (and visa versa) and Tor will function.

I’m not sure if there is something I’m missing that would make swapping torrc files between Whonix 13 and 14 something to be avoided ?

If swapping between versions is OK (or shouldn’t be done), I can add a notice box letting users know…

And once Whonix 14 is blessed stable i can remove the notice

Notice should stay up for a while as it may take a while for some users to upgrade to release 14

My last post requires clarification.

What I’m referring to when I say Whonix 13 and Whonix 14 torrc files are different.

Whonix 13 torrc

#This file is part of Whonix
#Copyright (C) 2012 - 2013 adrelanos <adrelanos at riseup dot net>
#See the file COPYING for copying conditions.

#Use this file for your user customizations.
#Please see /etc/tor/torrc.examples for help, options, comments etc.

#Anything here will override Whonix's own Tor config customizations in
#/usr/share/tor/tor-service-defaults-torrc

#Enable Tor through whonixsetup or manually uncomment "DisableNetwork 0" by
#removing the # in front of it.
<some_torrc_option>

Whonix 14 torrc file

##Tor user specific configuration file
##.
##Add user modifications below this line:
############################################
<some_torrc_option>

Normally, users could copy the entire torrc file over to the new sys-whonix.

qvm-copy /path/to/torrc sys-whonix-new

Upon further thought, not a good idea for migration of Whonix 13 torcc file to Whonix 14.

I will add short instructions to manually copy and paste torrc option from R13 to R14. Maybe mention this in info box with further instructions in footnote?

Will be completed later today.

Done!

https://whonix.org/w/index.php?title=Tor&oldid=33560&diff=cur

@torjunkie

I know you’re really busy but if you get a chance could you take a look at the edits. I’m a little iffy on the new heading and sub-heading titles.

Of course if you want to do a little polishing… :grin:

If any changes are needed please let me know!

@Patrick

Can you approve the “Encrypted Email with Thunderbird and Enigmail” page please? →

http://kkkkkkkkkk63ava6.onion/w/index.php?title=Encrypted_Email_with_Thunderbird_and_Enigmail&oldid=33449&diff=cur

It works for tempest, but I’ll give it a run through before linking to the main documentation page (and fix any minor errors that will no doubt appear).

That email section with the current page published is messy and needs a bit of work i.e. the existing “Mozilla Thunderbird with TorBirdy” page needs to be reworked & renamed (& possibly split into a couple of pages) on account of the proper instructions now drafted.

OK - will have a look soon.

Add to hardening list?

Anybody tried this with sys-whonix and anon-whonix i.e. vm-boot-protect? Apparently it works with Whonix.

Leverage Qubes template non-persistence to fend off malware. Lock-down, quarantine and check contents of /rw private storage that affect the VM execution environment.

vm-boot-protect.service:

  • Acts at VM startup before private volume /rw mounts

  • User: Protect /home desktop & shell startup executables

  • Root: Quarantine all /rw configs & scripts, with whitelisting

  • Re-deploy custom or default files to /rw on each boot

  • SHA256 hash checking against unwanted changes

  • Provides rescue shell on error or request

  • Works with template-based AppVMs, sys-net and sys-vpn

Also included is the ‘configure-sudo-prompt’ tool which restores authorization for sudo on Debian. vm-boot-protect isn’t effective with “passwordless sudo” Qubes default – this tool restores VM internal security using a dom0 yes/no prompt in place of passwords.

1 Like

torjunkie:

Add to hardening list?

GitHub - tasket/Qubes-VM-hardening: Fend off malware at Qubes VM startup

Yes, please.

torjunkie:

@Patrick

Can you approve the “Encrypted Email with Thunderbird and Enigmail” page please? →

http://kkkkkkkkkk63ava6.onion/w/index.php?title=Encrypted_Email_with_Thunderbird_and_Enigmail&oldid=33449&diff=cur

Excellent!

Some footnotes for justification required:

  • torbirdy from web rather than Debian package
  • –display-charset utf-8
  • –keyserver-options

…so we (including myself!) (not obvious when reading in half a year
from now) remember why this is useful and can check this is sane, and
still necessary in Whonix 14 / 15.

1 Like

Torrc migration looks almost perfect now.

torrc from Whonix 13 to Whonix 14:

I see no reason why conceptually the Tor data and/or Tor config
migration should not work:

This might likely work for Whonix 13 to Whonix 14 migration (and Whonix
14 to Whonix 14 migration):

sudo mv ~/QubesIncoming/sys-whonix-old/torrc

/usr/local/etc/torrc.d/50_user.conf

sudo chown -R debian-tor:debian-tor /usr/local/etc/torrc.d

(For Whonix 14 to Whonix 14 migration qvm-copy-to-vm from
/usr/local/etc/torrc.d/50_user.conf rather than from /etc/tor/torrc.)

1 Like

Updated torrc migration.

https:whonix.org/w/index.php?title=Tor&oldid=33688&diff=cur

Added short migration instruction for Whonix 13 → 14 , Whonix 14 → 14 in footnote. OK?

Step added to change torrc ownership to root:root. Didn’t catch torrc owned by user:user after migration.

Since Tor was still fully functional? Would it make a difference since Qubes has no sudo password? i.e. ownership - user vs root


This is the first round for possible new name, OG description. If nothing catches your fancy, I will come up with new ones :slight_smile:

New Name?

a) Whonix security model in the real world

b) Whonix security model Vs. real world threats

More catchy OG description?

a) How Whonix defeats many of the most notable “In the Wild” Attacks on Anonymity when others fall short. (when others fail?)

b) Whonix defeats many of leading attacks on anonymity. See how Whonix stacks up against other anonymity software when faced with the same threats.

Would this be OK to add to “Security in the Real World” (Draft)

Nautilus- a security bug was reported in Nautilus[1][2] file manager that would allow an attacker to disguise a malicious script as a .desktop file. In this attack, an adversary tricks the user into downloading the .desktop file from a website or sends the file in an email. Once the file is on the targets computer, the file (PDF, ODT) only has to be opened by the user for the script to execute. This security bug was used to craft an exploit which was used to break the Subgraph[3] security model[4]. Since Subgraph does not contain Nautilus in an oz sandbox, the malicious script would have access to much of the users data; PGP keys, SSH keys, stored email, documents, password databases, MAC address and nearby Wi-Fi access points could be a accessed. This could then be used by the attacker to deanonymize the user. Since Whonix-Workstation is isolated from the host and Whonix-Gateway. Even if a malicious .desktop script were to execute, no knowledge could be gained of the external IP address, hardware serials or sensitive user data. To be fair, when this bug was reported Subgraph OS was still in Alpha. Once Subgraph developers were informed of the vulnerability, the Subgraph Nautilus package was patched.

[1] Bug 777991 – Nautilus hides filename for .desktop files with execute permission
[2] linux.debian.bugs.dist.narkive.com/Z4frRjjC/bug-860268-desktop-files-can-hide-malware-in-nautilus
[3] Subgraph OS
[4] Breaking the Security Model of Subgraph OS | Micah Lee
[5] https://twitter.com/subgraph/status/852000407253594114

2 Likes

0brand:

Would it make a difference since Qubes has no sudo password? i.e. ownership - user vs root

Yes, very much so.

  • [1] Qubes by default has a sudoers exception for all commands run by
    user user. This is different from “no sudo password”. Full stop.
    Meaning, Qubes doesn’t totally deactivate the linux file permissinon system.
  • User permission rights are still crucial. Wrong permissions can break
    things.
  • Matters very much for Non-Qubes-Whonix.
  • We need correct file permissions since the days of [1] may be counted.
    I saw a github issue about that by Joanna but cannot find it anymore.
    However, there are people who deactivate passwordless sudo on Qubes.

Glad you come back to this one! :slight_smile:

This is the first round for possible new name, OG description. If nothing catches your fancy, I will come up with new ones :slight_smile:

New Name?

a) Whonix security model in the real world

b) Whonix security model Vs. real world threats

I like b).

More catchy OG description?

a) How Whonix defeats many of the most notable “In the Wild” Attacks on Anonymity when others fall short. (when others fail?)

b) Whonix defeats many of leading attacks on anonymity. See how Whonix stacks up against other anonymity software when faced with the same threats.

a) with “when others fail”.

Would this be OK to add to Security in Real World (Draft)

Excellent!

1 Like

Also good for advanced security guide?

1 Like

Is this the one you were referring to?

re: Qubes Vm Sudo good for security guide?

Yes!

I wonder if there is anything else in Qubes docs that should be added to Whonix wiki? Maybe?

I’ll go through Qubes doc to see.

1 Like

Security in Real World

OG description update
Nautilus (Subraph) exploit

Done!

https://whonix.org/w/index.php?title=Security_in_Real_World&oldid=33395&diff=cur

@torjunkie

I could use a little help with editing the wiki page name when you have a free moment. ( No rush )

I Could not find the wiki template?

Will also require opening permissions so I can make the edit. Unless you would like to do it. :

“Security in Real World” → “Whonix Security Model vs Real World Threats”

1 Like

Great! Will do (must check with tempest on some of that). Ditto hardening list.

Looks great - good job. Did some minor edits only.

OK - will have a look.

I’m not sure. I think it just pulls in the name of the page created explicitly. No major template there. Easiest way is to cut & paste into a properly named page? @Patrick

1. Re: TorBirdy version -

Jessie (old): 0.1.3-1
Jessie-backports (so-so): 0.2.0-1
Stretch:0.2.1-1
Buster, Sid: 0.2.4-1

Better 2.4. than not, right? Maybe an extra line stating:

“Users may optionally install the stable version from the stable repository (v0.1.3-1) or jessie backports (v0.2.0-1). The following method is preferred to have a later software version.”

2. Re: this on the existing Whonix email page (Mozilla Thunderbird with Enigmail + TorBirdy) →

It is different from tempest’s guide. Specifically the setting for “To send encrypted, accept”:

Whonix page says → Only keys I explicitly trust

Tempest guide → All usable keys / All valid keys I have

Not sure if it really matters.

3. This Whonix info below is all still valid? If so, I adopt it into the other page I created, and remove it from the Email page:

Keyserver

To interact with keyservers, you have various options.

a) KGpg: To fetch contacts' GPG keys from the key server open KGpg and go to Key Server Dialog. Search for email addresses you want to communicate with and import the keys.
b) gpg command line: You can use it as usual.
c) Enigmail's keyserver interaction features.
    Will not work out of the box. [3] [4]
    You need to apply the following setting every time you restart Thunderbird when you wish to interact with keyservers. [5] [6] [7] This may not be required anymore in Whonix 14.

Thunderbird → Enigmail (from menu bar) → Preferences → Display Expert Settings and Menus → Advanced → Additional Parameters → remove the following part --keyserver-options http-proxy=http://127.0.0.1:8118 → OK

High-Security Precautions

There have been bugs in email clients and Enigmail that lead to auto-saving of drafts as plaintext. [8][9] If you are in a life critical situation you may want to encrypt your emails in such a way as to not risk leaks.

Also it is always recommended to import private keys using Kgpg instead of directly with Enigmail to avoid unexpected behavior with message encryption.

  1. Open KGpg and select the recipient key (if more than one then hold CTRL while clicking).

  2. Go to: File → Open Editor and write your message.

  3. Encrypt message to ciphertext by clicking on the Encrypt lock icon and choose your private key in the prompt that comes up and OK.

  4. Copy the ciphertext into the email client and send it as you would normally (don’t include subject lines - those are not encrypted).

4. The rest of the Email page then needs a major edit and reorganisation etc.

A better structure is:

  • General Introduction
    – Warnings
  • Email Provider Comparison
    – Anonymity Friendly Email Provider List
  • Email Encryption (link to new page & delete existing section on Mozilla Thunderbird)
  • Email alternatives
    – Pretty Easy Privacy
    – BitMessage
    – Freemail
    – I2P-Bote
    – Anonymous Remailers

Actually charset and keyserver options steps are no longer required with TorBirdy v2.4 (it works without modification). So those steps will be deleted.

Fixed. Just needs a major edit for phrasing.

I already moved it all - executive decision. :slight_smile:

Qubes VM-sudo → wiki

Draft complete.

Should these instructions (i.e. draft) be combined/generalized with notations for any differences in steps for TemplateVMs?

This would greatly simplify steps. Although, if there are future TemplateVM specific changes in instructions, keeping it like it is now would make sense?


Replacing Password-less root Access with Dom0 User Prompt

Unlike traditional Linux operating systems, Qubes OS installs with a password-less root access by default in all VMs. Some may argue that this is a major security hole – but seeing as all user data is accessible from the user account – there would be no direct benefit for the attacker to to gain root privileges. However, there is nothing prevents a users from modifying their their own systems and enabling user/root isolation in VMs anyways.

Warning: The steps listed here are done so without any guarantee of safety, accuracy or completeness. Proceed at your own risk. Do not rely on this for extra security!

These instructions configure TemplateVMs to prompt Dom0 for all authorization request.

1.In dom0 terminal, add VMAuth service

sudo su

echo "/usr/bin/echo 1" >/etc/qubes-rpc/qubes.VMAuth

Exit from root prompt

exit

2.In dom0 terminal, open qubes.VMAuth in an editor

sudo nano /etc/qubes-rpc/policy/qubes.VMAuth

Add the following text.

$anyvm dom0 ask,default_target=dom0

Save and exit.

Note: If users would like to preserve password-less root access for individual VMs, a second line can be specified with the following text string.

<vm_name> dom0 allow

3.Configure TemplatesVMs to prompt dom0 for any authorization requests

Fedora

In Fedora TemplateVM, edit the system authentication setting

sudo gedit /etc/pam.d/system-auth

Remove all lines that begin with “auth” and replace with the following text.

auth [success=1 default=ignore] pam_exec.so seteuid /usr/lib/qubes/qrexec-client-vm dom0 qubes.VMAuth /bin/grep -q ^1$
auth requisite pam_deny.so
auth required pam_permit.so

Save and exit.

In Fedora TemplateVM, edit sudoers configuration file to require authorization for all requests

sudo gedit /etc/sudoers.d/qubes

Replace the first line with the following text.

user ALL=(ALL) ALL

Save and exit.

In Fedora TemplateVM, disable POlKit default-allow behavior

sudo rm /etc/polkit-1/rules.d/00-qubes-allow-all.rules

sudo rm /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla

Debian

In Debian TemplateVM, edit system authentication settings

sudo nano /etc/pam.d/common-auth

Remove all lines that begin with “auth” and replace with the following text.

auth [success=1 default=ignore] pam_exec.so seteuid /usr/lib/qubes/qrexec-client-vm dom0 qubes.VMAuth /bin/grep -q ^1$
auth requisite pam_deny.so
auth required pam_permit.so

Save and exit.

In Debian TemplateVM, edit sudoers configuration file to require authorization for all requests

sudo nano /etc/sudoers.d/qubes

Replace the first line with the following text

user ALL=(ALL) ALL

Save and exit.

In Debian TemplateVM, disable PolKit default-allow behavior

sudo rm /etc/polkit-1/rules.d/00-qubes-allow-all.rules

sudo rm /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla

In Debian TemplateVM, comment out the configuration line that allows root to su without password

sudo nano /etc/pam.d/su

Users should comment out (#) the following line

auth sufficient pam_rootok.so

Whonix

Note: Whonix users must complete steps in both whonix-ws and whonix-gw TemplateVMs

In Whonix TemplateVM, edit system authentication settings

sudo nano /etc/pam.d/common-auth

Remove all lines that begin with “auth” and replace with the following text.

auth [success=1 default=ignore] pam_exec.so seteuid /usr/lib/qubes/qrexec-client-vm dom0 qubes.VMAuth /bin/grep -q ^1$
auth requisite pam_deny.so
auth required pam_permit.so

Save and exit.

In Whonix TemplateVM, edit sudoers configuration file to require authorization for all requests

sudo nano /etc/sudoers.d/qubes

Replace the first line with the following text

user ALL=(ALL) ALL

Save and exit.

In Whonix TemplateVM, disable PolKit default-allow behavior

sudo rm /etc/polkit-1/rules.d/00-qubes-allow-all.rules

sudo rm /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla

In Whonix TemplateVM, comment out the configuration line that allows root to su without password

sudo nano /etc/pam.d/su

Users should comment out (#) the following line

auth sufficient pam_rootok.so

Note: If prompts appear when Whonix VMs are booting, users can create a configuration file to restore the VM to default passwork-less root access.

In Whonix TemplateVM, restore default VM operation (Only neccessary if prompts appear during boot)

sudo nano /etc/sudoers.d/zz99

Cut and paste the following lines into the new file

ALL ALL=NOPASSWD: /usr/sbin/virt-what
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck restart
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck start
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck stop
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck status

No idea.

Looks good!

Do not use the vm-boot-protect-root service for Whonix AppVMs.

Why not? This needs a justification / footnote. I am not aware what Whonix does differently so it would be breaking that.

Hi 0brand,

There was some discussion on Qubes forums about how adding password requirement didn’t really increase security. You could find it easy enough. Don’t know if that advice has really changed?

Anyway - thanks for all your Tor and other work. That copying across config / Tor state stuff was a big missing piece in that section, so it is very valuable. I’ve also referenced it in the hardening guide.

I think I read that on github stated by the author himself(?). Will find it and footnote why.

Other stuff

I’ve added a few things to the Hardening List and tidied that up.

One obvious (and mostly overlooked) security improvement in Qubes R4.0 would be setting the net-VM and firewall-VM to be disposable. I read somewhere that is possible, but didn’t see any instructions.

Anyone see this or attempt it?

I have zero doubt that advanced adversaries are focusing on / attacking Qubes users with hooks in the persistent directories, so that is one major attack vector that should be closed off ASAP.

Then, step two for greater security would be running the sandboxed (alpha) Tor Browser in a DispVM, which should be easy enough with the customized wiki guide we already have.

TO DO

  • Finish Encrypted Email small edits.
  • Tidy up general Email section.
  • Minor edit to Bridges documentation re: torrc difference between Whonix 13 & 14, based on feedback from pano
  • Finally get around to actually setting up that template that Patrick and Hulahoop requested about 10 pages ago. :slight_smile:
1 Like