There is another pitfall where a manually-created whonix-ws-based VM will inherit the default dispvm of the system (System Tools > Qubes Global Settings). This could potentially be a clearnet VM, which can then leak IP if the whonix-ws-based VM is compromised (e.g. it can open an html page in a clearnet browser that fetches a 3rd party resource).
It’s a non-issue for the Salt method - in fact, I believe this was one of the pitfalls that motivated automating the setup in Salt in the first place (the other being application of the anon-vm tag).
It’s also a non-issue if you’re simply re-using the existing sys-whonix, anon-whonix, of course.
Indeed, this is something users may not think to check i.e. Whonix DispVMs use clearnet
Another issue being the steps involved in creating the VMs are long and complicated. How many times have we changed the instructions? salt solves this as well. (thankfully)
Updated instructions (step 8) to use Qubes VM Manager as primary method to create sys-whonix and anon-whonix VMs. salt is an optional method. Opted to include detailed steps for VM creation in lieu of adding a link to documentation.
Do you think having users imitate old VM network settings would be easier or maybe less confusing than following the instructions the way they are now?
If any changes are needed (formatting, content etc.) please let me know.
It turns out ConnectionPadding 1 will not cause any trouble.
Using Sandbox 1 will git the following complains:
Apr 02 00:35:24.000 [notice] Read configuration file “/usr/share/tor/tor-service-defaults-torrc”.
Apr 02 00:35:24.000 [notice] Read configuration file “/etc/tor/torrc”.
Apr 02 00:35:24.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/torrc.d/95_whonix.conf (on Tor 0.3.2.10 )
Apr 02 00:35:24.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/torrc.d/95_whonix.conf (on Tor 0.3.2.10 )
Apr 02 00:35:24.000 [warn] Could not open “/etc/torrc.d/95_whonix.conf”: Permission denied
Apr 02 00:35:24.000 [warn] Error reading included configuration file or directory: “/etc/torrc.d/95_whonix.conf”.
Apr 02 00:35:24.000 [err] Reading config failed–see warnings above. For usage, try -h.
Apr 02 00:35:24.000 [warn] Restart failed (config error?). Exiting
I do not know what does “No interned sandbox parameter” means. Would you
like to ask on the tor-talk@ mailing list?
Looks like you’ve covered everything off (now you know why I dodged this task ).
I guess it’s up to the core team to decide now ie whether the simple testers guide as per no1’s 3 steps is preferred, or the full blown guide as per your entry. Or, the blog post could be a combination of:
Easy - quick testers guide with 3 steps
Advanced - full testers guide with 8 steps
I’m happy to further test Whonix 14 for full functionality, but it would be good for the experts to chime in with a simple yah or neh whether some of the things we are identifying are security risks or nothing to worry about e.g:
plethora of socks ports listening
“anon vm” tag issues in Qubes 4 with manual creation of VMs when not resorting to salt
Could call it false positives. This warnings don’t apply to Whonix. Many
SocksPorts for stream isolation. Listening on non-localhost so these are
reachable from Whonix-Workstations.
apparmor warnings on some profiles
Low priority. Might have been previously discussed. Please report
separately to Whonix AppArmor forums.
“anon vm” tag issues in Qubes 4 with manual creation of VMs when not
resorting to salt
For a “Testers Wanted” , its assumed users come to the table with the basic knowledge on how to use Qubes-Whonix – IMHO. The way the blog is written know is similar to how a wiki chapter is written. It would be helpful for inexperienced users but for the most part unnecessary. That is if you look at the current testers reporting back with issues. I’m not sure they need a detailed guide? Well, maybe unman but thats about it .
@0brand - Realized that for greater tester safety, we really should have a step where they explicitly copy & paste the Tor state file from Whonix 13 into the Whonix 14 VM before any Tor connections are made, to resist adversary efforts in tracking testers i.e. maintain same Tor guard.
I guess Whonix-Setup-Wizard will soon become deprecated (correct? @Patrick ). Currently, its behaviors are as follows:
kdesudo whonix-setup-wizard setup will:
if it is in Whonix-Gateway, start anon-connection-wizard
if it is in Whonix-Workstation, do nothing
kdesudo whonix-setup-wizard repository will open Whonix Repository whose shortcut has been provided separately.
kdesudo whonix-setup-wizard locale_settings will open locale settings, which are not very helpful considering Whonix does not support multi-languages currently.
I guess Whonix-Setup-Wizard will soon become deprecated (correct? @Patrick ). Currently, its behaviors are as follows:
We discussed in the ACW thread what it’s still needed for.
What the source files of https://github.com/Whonix/whonix-setup-wizard do is not implemented elsewhere. Not sure it should be implemented elsewhere. If implemented in ACW (possible of course) then ACW could become too Whonix specific. ACW source code would get bigger and less beautiful. At the moment the Whonix specific parts are as much as possible nicely sourced out to WSW.