I formatted and reinstalled to make absolutely sure I hadn’t messed anything up (like renaming sys-whonix), but now I get
[Dom0] Error
Default DVM failed:
unsupported operand type(s) for +:‘NoneType’ and ‘str’
Starting the whonix-gw-16 qube which worked last time now gives
Denied: qubes.UpdatesProxy
Denied qubes.UpdatesProxy from whonix-gw-16 to
Running whonix-gw-16: System Check gives
Could not check for software updates! (apt-get code: 255)
and tells me to run upgrade-nonroot in a whonix-gw-16 terminal.
Doing so gives
WARNING: Execution of /usr/bin/apt-get prevented by /etc/uwt.d/40_qubes.conf because no torified Qubes updates proxy found.
Please make sure Whonix-Gateway (commonly called sys-whonix) is running.
-If you are using Qubes R3.2: The NetVM of this TemplateVM should be set to Whonix-Gateway (commonly called sys-whonix)
-If you are using Qubes R4 or higher: Check your _dom0_/etc/qubes-rpc/policy/qubes.UpdatesProxy settings.
But there is no qubes.UpdatesProxy under _dom0_/etc/qubes-rpc/policy/
Sorry if I am asking stupid questions Please let me know what diagnostics you need and how I can gather them. Or should I be asking these question to Whonix rather than Qubes?
…it would also be useful to have the information described below to diagnose the situation…
Useful Info Step One - VM’s with whonix in their name and their template and netvm
Run following command in dom0… qvm-ls | grep -i -e name -e whonix
Useful Info Step Two - Are relevant services on, off or “default” and are relevant tags present or not
For each vm listed in Step One run the following two commands (in dom0) and post results… qvm-service vm-name qvm-tags vm-name
Useful Info Step Three - Contents of “old” Policy File
Check (in dom0) if the directory /etc/qubes-rpc/policy contains the file qubes.UpdatesProxy
If it does, then post the contents of the file.
Useful Info Step Four - Contents of new Policy Files
Run the following two commands (in dom0)… ls -l /etc/qubes/policy.d grep -i updatesproxy /etc/qubes/policy.d/90-default.policy
If you have created any other policy files e.g. 30-user.policy then do the same for those files too
E.g. grep -i updatesproxy /etc/qubes/policy.d/30-user.policy
Until now I thought I did.
Qubes security model relies on a system of hierarchical containment.
At the head is dom0, which contains one or more qubes with their own OS underneath. dom0 contains templates for different OS. For example during Qubes installation, you are offered Fedore, Debian and Whonix templates. Qubes created from these templates should pretty much work out of the box.
While actions inside an OS qube will not affect the template for that OS stored in dom0, OS qubes are persistent (relaunching a qube will remember your actions from last time).
To protect the OS qube, apps are run inside app qubes, which can either be semi-persistent (changes within the app’s own directory tree are persistent, changes outside this tree are not) or non-persistent (nothing will be remembered from the last time you launched that app qube). Neither can alter the OS qube they are run on or the templates they are based on, just like an OS qube can never alter dom0 or the template it was based on.
Of course, the qubes are running on virtual machines, the configuration of which is stored in the templates. The semi-persistent app qubes are running on what used to be called AppVMs, the non-persistent app qubes on what used to be called disposableVMs.
Am I in the right ball park?
I never tried to base any of these on Whonix. but if someone asked me, I’d say it’s mandatory them to be based on Fedora/Debian.
It is also not clear to me if you have sys-whonix automatically created during install?
Yes. The first is AppVM and also netVM, while the other is template?
I don’t know what does it mean. It’s not terminology usually used when Qubes is. If you said something like:
whonix-gw-16 and whonix-ws-16 are the templates on which sys-whonix and anon-whonix are based and automatically created upon during install, respectively
then I’d know what you were saying.
probably hosts better.
but you are
so
does sys-whonix exists on your system or not?
Wow, if someone asked me is this possible I’d say - no! Can you confirm that executing this command indeed crashed computer for more than once?
I’m not sure, because it is not clear if sys-whonix is automatically created during install, as you said.
sudo find / -name "*sys-whonix*" only returns /srv/formulas/base/virtual-machines-formula/qvm/sys-whonix.sls /srv/formulas/base/virtual-machines-formula/qvm/sys-whonix.top
So I think that means sys-whonix is NOT created during install and does NOT exist on the system, it certainly is not set as UpdateVM.
It does not, nor do sys-net, sys-firewall, anon-whonix, whonix-ws-16-dvm apparently:
sudo qubesctl state.sls qvm.anon-whonix
[user@dom0 /]$ sudo qubesctl state.sls qvm.anon-whonix
[ERROR ] ====== ['present'] ======
====== stderr ======
/usr/bin/qvm-create sys-net --class=AppVM --label=red
app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details.
====== ['prefs'] ======
Virtual Machine does not exist!
====== ['service'] ======
[SKIP] Skipping due to previous failure!
local:
----------
ID: template-whonix-ws-16
Function: qvm.template_installed
Name: whonix-ws-16
Result: True
Comment: Template whonix-ws-16 version 4.0.6 already installed
Started: 04:42:47.198897
Duration: 132.667 ms
Changes:
----------
ID: whonix-ws-tag
Function: qvm.vm
Name: whonix-ws-16
Result: True
Comment: ====== ['features'] ======
[SKIP] Feature already in desired state: ENABLE 'whonix-ws' = Enabled
====== ['tags'] ======
[SKIP] All requested tags already set: audiovm-dom0,created-by-dom0,guivm-dom0,whonix-updatevm
Started: 04:42:47.331929
Duration: 35.278 ms
Changes:
----------
ID: whonix-ws-update-policy
Function: file.prepend
Name: /etc/qubes-rpc/policy/qubes.UpdatesProxy
Result: True
Comment: File /etc/qubes-rpc/policy/qubes.UpdatesProxy is in correct state
Started: 04:42:47.369887
Duration: 7.105 ms
Changes:
----------
ID: whonix-get-date-policy
Function: file.prepend
Name: /etc/qubes-rpc/policy/qubes.GetDate
Result: True
Comment: Prepended 1 lines
Started: 04:42:47.377080
Duration: 1.53 ms
Changes:
----------
diff:
---
+++
@@ -0,0 +1 @@
+$tag:anon-vm $anyvm deny
----------
ID: template-whonix-gw-16
Function: qvm.template_installed
Name: whonix-gw-16
Result: True
Comment: Template whonix-gw-16 version 4.0.6 already installed
Started: 04:42:47.378685
Duration: 86.168 ms
Changes:
----------
ID: whonix-gw-tag
Function: qvm.vm
Name: whonix-gw-16
Result: True
Comment: ====== ['features'] ======
[SKIP] Feature already in desired state: ENABLE 'whonix-gw' = Enabled
====== ['tags'] ======
[SKIP] All requested tags already set: audiovm-dom0,created-by-dom0,guivm-dom0,whonix-updatevm
Started: 04:42:47.465192
Duration: 32.399 ms
Changes:
----------
ID: whonix-gw-update-policy
Function: file.prepend
Name: /etc/qubes-rpc/policy/qubes.UpdatesProxy
Result: True
Comment: File /etc/qubes-rpc/policy/qubes.UpdatesProxy is in correct state
Started: 04:42:47.497681
Duration: 1.98 ms
Changes:
----------
ID: sys-net
Function: qvm.vm
Result: False
Comment: ====== ['present'] ======
====== stderr ======
/usr/bin/qvm-create sys-net --class=AppVM --label=red
app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details.
====== ['prefs'] ======
Virtual Machine does not exist!
====== ['service'] ======
[SKIP] Skipping due to previous failure!
Started: 04:42:47.499742
Duration: 341.155 ms
Changes:
----------
ID: sys-firewall
Function: qvm.vm
Result: False
Comment: One or more requisite failed: qvm.sys-net.sys-net
Started: 04:42:47.841501
Duration: 0.004 ms
Changes:
----------
ID: sys-whonix
Function: qvm.vm
Result: False
Comment: One or more requisite failed: qvm.sys-firewall.sys-firewall
Started: 04:42:47.841785
Duration: 0.003 ms
Changes:
----------
ID: whonix-ws-16-dvm
Function: qvm.vm
Result: False
Comment: One or more requisite failed: qvm.sys-whonix.sys-whonix
Started: 04:42:47.844334
Duration: 0.003 ms
Changes:
----------
ID: qvm-appmenus --update whonix-ws-16-dvm
Function: cmd.run
Result: False
Comment: One or more requisite failed: qvm.whonix-ws-dvm.whonix-ws-16-dvm
Started: 04:42:47.844404
Duration: 0.002 ms
Changes:
----------
ID: anon-whonix
Function: qvm.vm
Result: False
Comment: One or more requisite failed: qvm.whonix-ws-dvm.whonix-ws-16-dvm, qvm.sys-whonix.sys-whonix
Started: 04:42:47.844555
Duration: 0.002 ms
Changes:
Summary for local
------------
Succeeded: 7 (changed=1)
Failed: 6
------------
Total states run: 13
Total run time: 638.296 ms
DOM0 configuration failed, not continuing
Yes, twice. Not an instant crash to power-off, but first the terminal freezes, then the cursor, then the fans become loud, finally it shuts down completely.
Does that nean that one of the Qubes update proxies is directly proxied to Zion, and that’s why Whonix denies to have anything with Zion? Busted?
Please mark it as a solution, if so
/etc/qubes-rpc/policy/qubes.UpdatesProxy is an artifact of Q4.0
Mine, configured to use cacher, also making update proxy accept appvm update proxy request, which is configured by adding service.updates-proxy-setup through qvm-features AppVM ServiceName on so that my TemplateVMs configured to use cacher, so that appvm volatile layer can contain app install for a single boot. Just to explain the content of the following:
Mainly, anyone using Q4.1 should not rely on /etc/qubes-rpc/policy/qubes.UpdatesProxy anymore, but should use /etc/qubes/policy.d/30-user.policy to specify deviations to default and get rid of /etc/qubes-rpc/policy/qubes.UpdatesProxy.
Since you are using sys-whonix as an update proxy, yours should look like the following:
The following line: qubes.UpdatesProxy * @type:TemplateVM @default allow target=sys-whonix
Tells that any TemplateVM will be able to use sys-whonix offered proxy.
Getting rid of /etc/qubes-rpc/policy/qubes.UpdatesProxy is a good idea under Q4.1.
NOTE: precedence is important. The defaults are under higher number of policies:
So if nothing is defined under 30-user.policy, then the defaults will be applied. And of course, /etc/qubes-rpc/policy/qubes.UpdatesProxy interferes in that (not sure what is read first here still today, so hence removing /etc/qubes-rpc/policy/qubes.UpdatesProxy is my recommendation.
The issue to remove (comment out) deprecated /etc/qubes-rpc/policy/qubes.UpdatesProxy is stalled upstream:
What are your recommendations when this happens in R4.2? There is no rpc or 30 salt policy. I added 30-user.policy but the update never starts. Debian and Fedora sources are not onionized so updates over tor can be blocked unlike with Whonix. In that case, should I manually configure templates not to update over tor? What is the best way to do that? Thanks.
I came accross the same issue after restoring backup and then replacing ‘sys-net’ to ‘sys-net1’.
Renaming ‘sys-net1’ to ‘sys-net’ fixed the issue in my case.
I assume users easily fall into this problem because there is no protection from removing UpdateProxyVM.