Hi @0brand,
There’s some good stuff there. I’m happy to edit it, but I guess I’ll wait for any reworking first.
Hi @0brand,
There’s some good stuff there. I’m happy to edit it, but I guess I’ll wait for any reworking first.
It looks like- right idea, wrong interpretation . I assumed “company” meant a large well established project (had grown into a large open-source company) and maybe Whonix was a small open-source company. Oops
This is probably one of the reasons why I was having so much trouble writing this.
I really appreciate you taking the time to get me pointed on the right track. I’ll start working on this right away!
Sound good. As soon as this is complete I’ll start on the “Qubes R4 adjustments for DisposableVMs”
A continually updated chart of mainline hardening defenses:
What would be an appropriate section to add a “kernel hardening status” section to for user reference?
Could this table (DispVM vs inheritance etc.) please be copied to the wiki?
For the changelog. Mostly fixes for Qubes R4 and DispVMs.
I’ll find a home for this table as soon rewrite of Linux Distro vs Windows?? (not sure of title yet) is completed. This is going a little slow as well but I’m starting to make good progress.
→ Fixed
Agree with 0brand, that might be a good location for Kernel stuff? Are you going to replicate all that in a mega-table @HulaHoop?
0brand, can you check the onionizing repositories stuff in the security guide? Nothing for Qubes R4, and I’m not sure those old instructions will work.
@Patrick, it’s pretty hard to make head or tails sometimes of those github links re: updates to Release Notes. Much easier from phabricator to see what is actually going on i.e. some basic description.
Also that Authorship page needs further clean up towards the bottom. I may well cut out Sources and 3rd party images to separate pages etc.
Edit: Tor 3.3.6 etc working fine in Qubes-Whonix. 3.3 series will make it to Whonix 14 stable repo I presume
I went through the onionizing repos docs (tested everything) and most of it looks good.
These are my proposed changes
1. Qubes onionizing: Fedora, Debian, Whonix Templates
Use a wildcard ( * ) in command lines so they work for both qubes-r3
and qubes-r4
Example: (tested, works)
.../etc/apt/sources.list.d/qubes-r3.list && cat /etc/apt/sources.list.d/qubes-r3.list'
.../etc/apt/sources.list.d/qubes-r* && cat /etc/apt/sources.list.d/qubes-r*'
2. Whonix and Debian Packages
Currently makes reference to “jessie” in section which users must copy and paste into their repo file.
#deb Index of /debian jessie main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie main contrib non-free
3. Onionize Tor Project Updates
Qubes R4: Since the connection fails when adding the Tor Project deb apt signing key in the TemplateVM. Make note for users to follow instruction in a StandaloneVM.
4. Change all instructions to use v3 .onions and make note of Qubes,Whonix v2 .onion addresses??
@torjunkie Thanks! I needed a little change of pace.
In the onioizing Qubes packages command lines these are not considered varliables are they? If so they never worked.
$FedoraTemplateVM
$DebianTemplateVM
It never made sense to me that instructions would have users onionize all
TemplateVMs sinced your supposed to keep 1 template each for Debian Fedora etc. in unaltered state. For testing etc.I assumed users where required to replace e.g. $FedoraTemplateVM with Fedorea-26.
If I’m wrong that needs to be changed to
<your_template_vm>
Too little thing for the effort of a StandaloneVM. gpg / apt-key can probably use networking when requests are going through Qubes updates proxy. Another option would be fetching the key in a networked VM and then copying it over as text or file.
That would be great if you could fix those instructions 0brand! It all looks very sensible.
You are great with technical steps and breeze through that stuff. I’m actually very jealous
No. too much unnecessary work. All I wanted was to point users to info on bug mitigation advancements in the kernel so they can assess their sec situation.
Double up in Anonymity System Comparison section:
Build script: apt-get unreliable exit code security workaround
(Miscellaneous section)
&
apt-get unreliable exit code security workaround
(Updates section).
Suggest you get rid of one or the other (or let me know).
In case your wondering whats taking so long for the onionizing repos edits. I’m currently working on the above for Q4 users and and instructions to revert repositories back to http/URI (if needed).
This way I can get everything done at the same time.
Comparison with Others -> Fixed.
(piece of cake, only 215 footnotes there…)
Next, finish off Authorship page, then split security guide as discussed earlier.
Realized that Screenshots page also badly needs updating:
a) logical structure
b) more categories
c) updated screenshots (particularly Qubes-Whonix)
Happy to snap away some shots, but surely many of these are already on the server.
Not sure if the easiest way to find images is Special:ListFiles ? or Special:NewFiles?
Also, as well as that idea for short list of cli commands for various entries, we should maybe put up a more pics at the top of each wiki entry, related to the topic? Make it look prettier and less encyclopaedic?
Reminder - @0brand - this page is always useful in the search bar ->
Special:SpecialPages
Done!
Qubes onionizing instructions are a little confusing for less experienced users? If a typo was made in the .onion address they may not know how to correct the mistake. Tried adding minimal instructions using a text editor for mess up corrections and for reverting to http:// URI ( if necessary). But it just added clutter/confusion IMO
Onionizing Repositories
When Whonix, Debian and Qubes packages are installed or updated, default settings point to repositories with a http:// URI. [ref]Whonix APT Repository However, experimental Tor onion services are already available for the Whonix, Debian and Qubes packages.
Utilizing Tor onion services provide several security and privacy benefits: [ref]https://blog.torproject.org/blog/tor-heart-apt-transport-tor-and-debian-onions[/ref]
- The user cannot be uniquely targeted for malicious updates (an adversary is forced to attack everyone requesting the update).
- The package repository, or observers watching it, can’t track what programs are installed.
- The ISP cannot easily learn what packages are fetched.
- End-to-end authentication and encryption provides protection against man-in-the-middle attacks e.g. version downgrade attacks.
[start/infobox]
While Qubes and Whonix maintain both v2 and v3 onion addresses, users are strongly encouraged to enforce v3 onion connections. This allows users to benefit from the many improvements over the v2 legacy system[ref][NextGenOnions · Wiki · Legacy / Trac · GitLab],aka prop224[/ref] [footnote]Tor v3.2 or higher must be running in Whonix-Gateway (sys-whonix
).[/footnote]
[end/Infobox]Qubes Packages
The following commands must be run in dom0 to configure TemplateVMs to use Qubes’ Tor onion service repositories. [ref]The cat commands are optional and for confirmation only.[/ref]
The downside of this approach is that repository definitions are managed by a Qubes package, meaning manual updates are needed if the the definitions change in the future.
[start/infobox]
Users that are currently forcing v2 onion connections can update to v3 connections by replacing all instances of the http/URI address (qubes-os.org) below with qubesos4rrrrz6n4.onion
[end/infobox]Dom0
In dom0, run.
sudo sed -i 's/yum.qubes-os.org/yum.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion /' /etc/yum.repos.d/qubes-dom0.repo && cat /etc/yum.repos.d/qubes-dom0.repo
sudo sed -i 's/yum.qubes-os.org/yum.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion /' /etc/yum.repos.d/qubes-templates.repo && cat /etc/yum.repos.d/qubes-templates.repo
Fedora Template
In dom0, run.
qvm-run -a --nogui -p -u root <your_fedora_template> 'sed -i "s/yum.qubes-os.org/yum.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion/" /etc/yum.repos.d/qubes-r* && cat /etc/yum.repos.d/qubes-r*'
Debian and Whonix Templates
In dom0, run.
qvm-run -a --nogui -p -u root <your_debian_template> 'sed -i "s/deb.qubes-os.org/deb.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion/" /etc/apt/sources.list.d/qubes-r* && cat /etc/apt/sources.list.d/qubes-r*'
Whonix and Debian Packages
[start/infobox]
Tip: Whonix 14 will prefer v3 Tor onion services (.onion repositories) by default, even when adding third-party resources.
end/infobox]Until Whonix 14 is released, users may consider manually editing their sources.list to point to the Whonix and Debian .onion mirrors in order to install or update more securely.
The whonix.list and debian.list files in the /etc/apt/sources.list.d directory should be changed in both the Whonix-Workstation and Whonix-Gateway. Qubes-Whonix users note: Complete these steps in the
whonix-gw
andwhonix-ws
TemplateVMs.1. Edit sources.list
In the Whonix-Gateway, edit the debian.list file using 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. Reference the Onionized Debian Repositories
Cut and paste the following
.onion
mirrors and comment out (#) the corresponding http repositories.#deb Index of /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 Index of /debian jessie-backports main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie-backports main contrib non-freeSave and exit.
3. Reference the Onionized Whonix APT Repository
[start/infobox]
Tip: Whonix users have four package preferences available: stable, stable-proposed-updates, testers and developers. Change the entry below to reflect this preference. [ref]Whonix APT Repository
[end/infobox]To use the v3 onion, run. [footnote]Requires Tor v3.2 or above running in Whonix-Gateway (
sys-whonix
).[/footnote]
sudo whonix_repository --baseuri http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion --enable --repository stable
4. Confirm the Onionized Repositories are Functional
sudo apt-get update && sudo apt-get dist-upgrade
5. Repeat Steps 1 to 4 for the Whonix-Workstation
[start/infobox]
Tip: Qubes users can repeat these steps in the Debian TemplateVM to onionize future installations and updates.
[end/infobox]6. Optional: Onionize Tor Project Updates
Only complete this step if the Tor versions from The Tor Project repository are being used. The Tor Project deb apt signing key must be added first (see the link above), or the user will receive error messages when completing these steps.
The following commands are run in either the Whonix-Gateway or
whonix-gw
TemplateVM (Qubes-Whonix-R3.2 ).Qubes-R-4.0 only! Since TemplateVMs are non-network connected by default,[ref]https://github.com/QubesOS/qubes-issues/issues/1854[/ref] any attempt to download the apt key from
whonix-gw
will fail. To work around this issue users can fetch the Tor apt singing key from a (networked)anon-whonix
AppVM. Then copy the signing key over towhonix-gw
in a text file.To add the Tor Project deb apt signing key, run. (In
anon-whonix
konsole for Qubes-R4.0)Note: Whonix 14 users must replace the keyserver address keys.gnupg.net with .onion address jirk5u4osbsr34t5.onion
sudo apt-key adv --keyserver keys.gnupg.net --recv-keys A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
To display the keys fingerprint, run. (In
anon-whonix
for Qubes-R4.0)
sudo apt-key adv --fingerprint A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
Compare the fingerprint displayed in terminal with the one listed on this website How can we help? | Tor Project | Support
(Qubes-R4.0 only!) In
anon-whonix
, copy the Tor singing key to a new text file named tor.key.
sudo apt-key export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 > /tmp/tor.key
(Qubes-R4.0 only!) In
anon-whonix
, copy the Tor singing key text file over towhonix-gw
, run.Note: If users encounter the following error it can be safely ignored.
qfile-agent: Fatal error: stat whonix-gw-version (error type: No such file or directory)
qvm-copy /tmp/tor.key whonix-gw
(Qubes-R4.0 only!) In
whonix-gw
, add the Tor signing key to the list of trusted keys.
sudo apt-key add ~/QubesIncoming/anon-whonix/tor.key
To onionize Tor Project updates first create a torproject.list file using an editor with root rights.
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
Next, cut and paste the following text and comment out (#) the corresponding http repository.
#Tor Project Mirror
#deb Index of /torproject.org jessie main
deb http://sdscoq7snqtznauu.onion/torproject.org jessie mainSave and exit.
@torjunkie As requested (can’t find the post from earlier), I tested Whonix 14 Sandboxed Tor Browser DispVM. Im aware Tor Project has officially abandoned its development. However wanted to let you know:
everything worked OK (now moot)
a new Child Ticket was created to Remove Tor Browser Sandbox from the Download Page.
This will effectively kill sandboxed? Should be remove from wiki?
Very good!
Yes. Please move to Outdated, Deprecated, Archived Whonix Documentation..
Very good 0brand. Please go ahead and make the necessary changes, and I’ll nitpick later on.
(Off topic: Did anyone ever mention that wiki editing is a thankless, painful, and lonely task? Note to self: resist urge to take permanent holiday )