torjunkie:
Add to hardening list?
GitHub - tasket/Qubes-VM-hardening: Fend off malware at Qubes VM startup
Yes, please.
torjunkie:
Can you approve the “Encrypted Email with Thunderbird and Enigmail” page please? →
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 
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] Bug#860268: .desktop files can hide malware in Nautilus
[3] Subgraph OS
[4] Breaking the Security Model of Subgraph OS
[5] https://twitter.com/subgraph/status/852000407253594114
2 Likes
0brand:
Would it make a difference since Qubes has no
sudopassword? i.e. ownership -uservsroot
Yes, very much so.
- [1] Qubes by default has a sudoers exception for all commands run by
useruser. 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!
This is the first round for possible new name, OG description. If nothing catches your fancy, I will come up with new ones
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
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.
Open KGpg and select the recipient key (if more than one then hold CTRL while clicking).
Go to: File → Open Editor and write your message.
Encrypt message to ciphertext by clicking on the Encrypt lock icon and choose your private key in the prompt that comes up and OK.
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.
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.
1 Like
I would agree that adding password requirements for root does not substantially improve security for VMs.
However, there has been further discussion on Github. After reading this Qubes issue that tasket created, it seems there would be a small benefit to configuring dom0 to promt for sudo authorization?
tasketVery understandable, since VM isolation must remain the paramount organizational principle for Qubes (both in terms of code and motivations). I’m actually glad the community has been able to evolve without the conventional security mindset. Yet, spotty as guest OS security is, in Qubes it represents a measure of security offered but not taken, even though Qubes integration makes it resemble the ease of Windows UAC. There is also the question of whether our VMs appear to be easily-acquired resources for attackers (i.e. the ‘welcome mat’ layed out), which promises to be at least a nuissance factor in operations.
tasket
Apart from the possibility of protecting Xen, I feel that offering root capabilities within VMs – without resistance – could make Qubes guests attractive resources to attackers of just about any skill level.
Its hard to get a handle on the entire thread by reading these two snippets but if there is even a small benefit should the documentation (how to) be offered to Whonix users? With a disclaimer. 
Edit: Qubes-VM-hardening also disables Qubes default password-less root and has a tangible security benefit. This chapter is now moot. No?
2 Likes
Yes, I’m using both ATM
IIRC setting up the sys-net was a PITA. I can’t remember exactly what the problem was. I had to use part command line, part GUI (which I hardly ever use) to finalize the config.
Belay my last! I just remembered what the problem was!
I had to use the GUI to set VM class to HVM and select the PCI devices i.e. Ethernet card, Wireless card. If I tried to use the CLI sys-net would just hang or not start.
If you like I can come up with steps for sys-net, sys-firewall (dvm and DispVM). Will need both since pci devices need to be set to sys-net DispVM not dvm. Although I’m gnawing at the bit to start the “One Time Pad” wiki chapter, I guess its not going anywhere. 
2 Likes
That would be excellent 0brand and instructions would be a significant security enhancement. I for one would very much welcome it, since I haven’t investigated the issue at all.
I’m glad you’ve managed it!
Agree the issue is moot re: enforcing passwords in Qubes, given the VM hardening tool enforces that anyhow, and provides a much higher security standard. So save your efforts for more valuable things.
1 Like
These steps work for me 9 out of 10 times for net-disp, 10 out of 10 for firewall-disp. The troubleshooting section fixes any problems with attaching PCI device and net-disp not booting. After completion, the new VMs function the same as AppVMs only non-persistent.
Q: If the PCI device is attached to the service-dvm will net-disp inherit the attached PCI device?
A: No, I tried that numerous times, does not work
Q: What do you mean by "the new DispVMs function like AppVMs only non-persistent?
A: These new service VMs can be set to auto-start, can be NetVM for other AppVMs, PCI devices can be attached and will be attached at every VM boot (persistent) with no user input required. DispVM for the most part can be used the same as a regular AppVM.
Q What names should the DispVMs be given in the steps?
A: ?
Q: Should the steps be broken up (Section 1. create service-dvm) (Section 2. create net-disp) (Section 3. create firewall-disp) (Section 4. starting VMs) (Section 6. troubleshooting)
A: ?
Off topic: Also VPN DispVMs and USB DispVMs <–working on this now) can be created 
Please let me know what changes need to be made to the instructions
Create sys-net and sys-firewall Disposable VMs
Qubes R4.0 only!
Qubes users can configure both the sys-net and sys-firewall VMs as Disposable VMs. Using DispVMs for service VMs has the advantage of preventing malware from getting persistent hooks in the VMs’ filesystem. Whereas AppVMs /home folder is persistent accross reboots, when a DisposableVM is shutdown, the VM is removed from Qubes and all related VM images are deleted from the host filesystem. Since fresh VMs are created every time a Dispvm is started, this ensures no malware could remain persistent across reboots.
Note: if users intend to use the same naming convention for the new VMs as currently on their system. The old sys-net and sys-firewall VMs must either be deleted or cloned with a new name.
These steps create the service-dvm (template for DispVMs) net-disp (Dispvm) and firewall-disp (Dispvm)
1. In dom0, create the dvm that will be used as Template for service DispVMs
qvm-create -P <pool_name> --template <template_name> --class AppVM --label gray service-dvm
2. In dom0, set service-dvm virtualizaion mode to hvm
qvm-prefs service-dvm virt_mode hvm
3. In dom0, set service-dvm as template for disposable VMs
qvm-prefs service-dvm template_for_dispvms true
4. In dom0, create net-disp DispVM based on service-dvm
qvm-create -P <pool_name> --template service-dvm --class DispVM --label red net-disp
5. In dom0, set net-disp to provide network for other VMs
qvm-prefs net-disp provides_network true
6. In dom0, set net-disp NetVM to none
qvm-prefs net-disp netvm ""
7. In dom0, list all available PCI devices to determine the correct backend:BDF address(es) to assign to net-disp
Note: the bakend:BDF address will look similar to this dom0:00_1a.0
qvm-pci
8. In dom0, attach the network PCI device(s) to net-disp
Note: if 00_1a.0 is the BDF of the Ethernet controller that will be assigned to net-disp, the command would look similar to this: qvm-pci attach --persistent net-test dom0:00_1a.0
qvm-pci attach --persistent net-disp <backend>:<bdf>
9. (Optional) In dom0, set net-disp to start automatically when Qubes boots
qvm-prefs net-disp autostart true
10. (Optional) In dom0, set net-disp as the dom0 time source
qubes-prefs clockvm net-disp
11. In dom0, create firewall-disp
qvm-create -P appvm_pool --template service-test --class DispVM --label green firewall-disp
12. In dom0, set firewall-disp to provide network for other VMs
qvm-prefs firewall-disp provides_network true
13. In dom0, set net-disp as NetVM for firewall-disp
qvm-prefs firewall-testing netvm net-testing
14. In dom0, set firewall-disp as NetVM for other AppVMs
qvm-prefs <vm_name> netvm firewall-disp
15. (Optional) In dom0, set firewall-disp to auto-start when Qubes boots
qvm-prefs firewall-disp autostart true
16. (Optional) In dom0, set firewall-disp as the default NetVM
qubes-prefs default_netvm firewall-disp
Starting net-disp and firewall-disp VMs
Prior to starting net-disp, users must ensure that no currently running VMs – such as the current sys-net – has the same PCI device attached. These VMs must be either shutdown or the PCI device detached.
Once VMs have been successfully started, users should ensure no other VMs will interfere with the VMs at the next Qubes boot. If the new net-disp VM and the current sys-net VM are both set to auto-start – and have identical PCI devices attached – may lead to failed starts for both VMs.
1. In dom0, start net-disp
qvm-start net-disp
2. In dom0, start firewall-disp
qvm-start firewall-disp
Troubleshooting
If users see an error stating “The PCI device could be attached”, rebooting the Qubes system will likely rectify the problem. After net-disp boots successfully for the first time, users should have no further VM boot problems. The network PCI device will be attached with every VM boot without the need to manually attach proir to every VM start.
2 Likes
My last post “Creating sys-net and sys-firwall Disposable VMs” instructions has been extensively modified
Steps added to create firewall DispVM,
All other steps have been updated as well
2 Likes