Related -> Qubes-Whonix 14 Salt Issue
I presume the anon-vm tag and salt issues for configuration / downloading of new Whonix 14 templates are the only blockers for Qubes-Whonix 14.
Since the salt issue has stalled, it might be helped along by this individual below (vic viq), who claims to be a salt expert and has put his hand up to help in the qubes-devel forums during the last week ->
https://groups.google.com/forum/?_escaped_fragment_=topic/qubes-devel/EfQCiYcnc4g#!topic/qubes-devel/EfQCiYcnc4g
Suggest you call on this offer.
2 Likes
torjunkie:
Related → Qubes-Whonix 14 Salt Issue
I presume the anon-vm tag and salt issues for configuration / downloading of new Whonix 14 templates are the only blockers for Qubes-Whonix 14.
Yes.
Also…
https://phabricator.whonix.org/T781
https://phabricator.whonix.org/T726
(might be duplicate)
All tasks (but these are less important, shouldn’t block release):
https://phabricator.whonix.org/maniphest/query/m5ldmi_.8fg1/#R
Since the salt issue has stalled, it might be helped along by this individual below (vic viq), who claims to be a salt expert and has put his hand up to help in the qubes-devel forums during the last week →
https://groups.google.com/forum/?_escaped_fragment_=topic/qubes-devel/EfQCiYcnc4g#!topic/qubes-devel/EfQCiYcnc4g
Suggest you call on this offer.
Excellent find! Done, asked.
2 Likes
This will soon be resolved, hopefully. Soon available form Qubes testing repository.
Qubes ticket:
Available for Qubes current-testing.
1 Like
Not a blocker, but really really bad to ensure there won’t be leaks due to user configuration mistake.
opened 09:02AM - 14 Jun 18 UTC
T: enhancement
C: core
P: major
privacy
C: Whonix
### Qubes OS version:
R4 and above
### Affected component(s):
dom0, Whonix
… ### Steps to reproduce the behavior:
Set NetVM of anon-whonix to default (sys-net).
Then use system default networking `curl.anondist-orig https://check.torproject.org` or otherwise to connect to clearnet.
### Expected behavior:
Secure defaults. No clearnet connections possible through small user configuration mistake / oversight.
### Actual behavior:
Insecure defaults. Clearnet leak.
### General notes:
Qubes UpdatesProxy mechanism currently is more likely to produce a leak in future. A leak as in a user expecting to have connections torified while these are over clearnet.
The problem is, that https://github.com/QubesOS/qubes-core-admin/blob/master/qubes-rpc-policy/qubes.UpdatesProxy.policy by default says `$type:TemplateVM $default allow,target=sys-net`. And sys-net traffic isn't torified by default. Therefore, if any of the following goes wrong (salt / tags / qvm-features maybe / qubes-core-admin-addon-whonix), Whonix TemplateVMs might connect through clearnet. Would be better if `qubes.UpdatesProxy.policy` only included `$anyvm $anyvm deny` and then opt-in each and every TemplateVM rather than an opt-out approach.
When the user wants torification, the default non-torification setting needs to be overwritten. This is done by salt:
* https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/template-whonix-gw.sls - which depends on `tag:whonix-updatevm`
* https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/updates-via-whonix.sls
And then there is also https://github.com/QubesOS/qubes-core-admin-addon-whonix.
The user accidentally setting a whonix-ws based AppVM such as anon-whonix to NetVM default (sys-net) results in `curl.anondist-orig https://check.torproject.org` being able to reach it over clearnet. This is a huge disadvantage over the VirtualBox version of Whonix where such mistakes are very very unlikely to happen. (Because the Whonix-Workstation VirtualBox version of Whonix has only an internal network card (in internal network `whonix`) - which cannot accidentally connect to clearnet.)
----
Qubes-Whonix has code to detect wrongly configured Qubes updates proxy settings and refuses to upgrade but that's just a workaround and more complexity (possible including bugs leading to situations where users cannot upgrade or false-positive warnings).
* https://github.com/Whonix/qubes-whonix/blob/master/etc/uwt.d/40_qubes.conf
* https://github.com/Whonix/qubes-whonix/blob/master/usr/lib/qubes-whonix/init/torified-updates-proxy-check
* https://github.com/Whonix/qubes-whonix/blob/master/lib/systemd/system/qubes-whonix-torified-updates-proxy-check.service
There's also `whonixcheck --leak-tests`.
It's not a real fix, not as strong as a technical guarantee as it could be.
----
It's a complex design and interaction. Hard to fully understand (more so the more time passes). Prone for bugs in future or user mistake.
In summary, Qubes default and technical design currently is: network-enabled, clearnet, options to change to network-disabled or torified
For better control of connections the technical design should be: non-networked by default and then opt-in networking by using salt / core-admin-addon's.
opened 09:02AM - 19 Jun 18 UTC
closed 06:04PM - 17 Jul 18 UTC
T: task
C: Whonix
This will become the stable version if no grave bugs are reported.
once testing this version is done, Whonix 14 will be released.
1 Like
Besides the known bugs on the Whonix and Qubes issue trackers, Whonix 14 should be ready as stable Whonix 14 release. Only waiting for new Qubes templates to be built and tested before the Whonix 14 release will be made .
1 Like
Time to unleash its greatness? Wohoo!
1 Like
When testing is done and no grave issues reported, Whonix 14 will be released.
1 Like