Denied: qubes.UpdatesProxy

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 :sweat_smile: 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?

I need to know if you know what is template and what is AppVM and what is disposabelVM first in order to know how to help you.

In addition to answering enmus question…

…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?

whonix-gw-16 (TemplateVM)
whonix-ws-16 (TemplateVM)

qvm-service whonix-gw-16 either crashes the computer or returns nothing

qvm-service whonix-ws-16 returns nothing

qvm-tags whonix-gw-16 and qvm-tags whonix-ws-16 both return:
audiovm-dom0
created-by-dom0
guivm-dom0
whonix-updatevm

It does not.

total 40
-rw-rw-r-- 1 root root 674 Mar 5 2022 35-compat.policy
-rw-rw-r-- 1 root root 829 Feb 18 2022 80-whonix.policy
-rw-rw-r-- 1 root qubes 2150 May 4 02:00 85-admin-backup-restore.policy
-rw-rw-r-- 1 root qubes 7602 May 4 02:00 90-admin-default.policy
-rw-rw-r-- 1 root root 1129 Mar 5 2022 90-admin-policy-default.policy
-rw-rw-r-- 1 root qubes 6331 May 4 02:00 90-default.policy
drwxrwxr-x 2 root root 4098 Oct 15 00:18 include
-rw-rw-r-- 1 root root 185 Mar 5 2022 README

#qubes.UpdatesProxy * @type:TemplateVM @default allow target=sys-whonix
qubes.UpdatesProxy * @tag:whonix-updatevm @default allow target=sys-whonix
#Deny Whonix TemplateVMs using UpdatesProxy of any other VM.
qubes.UpdatesProxy * @tag:whonix-updatevm @anyvm deny
qubes.UpdatesProxy * @type:TemplateVM @default allow target=sys-whonix
qubes.UpdatesProxy * @anyvm @anyvm deny

I have not.

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?

1 Like

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.

I’ve now manually added the following /etc/qubes-rpc/policy/qubes.UpdatesProxy to no avail.

It is not needed it remains only for compatibility with R4.0 (check 35-compat.policy for this), 90-default.policy is enough.

I think we reached the point where you should tell us what is your goal by not installing fedora and debian templates.

off-topic

Wait, how Chinese communists fit into this?

off-topic

No really, please elaborate why is Qubes a joke and honey pot. How come you concluded this?

off-topic

As a proud Chinese communist I object to being lumped together with
those eastern European apostates.

off-topic

Expecting Jewish banksters and Islami fanatics to object missing…

off-topic

It’s a little known fact that the original Qubes specification was taken directly from
the protocols of the elders of Zion.

off-topic

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:

[user@dom0 ~]$ sudo cat /etc/qubes/policy.d/30-user.policy 
qubes.UpdatesProxy  *  @anyvm  @default  allow target=cacher
#qubes.UpdatesProxy  *  @tag:whonix-updatevm    @default    allow target=sys-whonix
#qubes.UpdatesProxy  *  @type:AppVM  @default  allow target=cacher
#qubes.UpdatesProxy  *  @type:TemplateVM  @default  allow target=cacher

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:

[user@dom0 ~]$ sudo cat /etc/qubes/policy.d/30-user.policy 
#qubes.UpdatesProxy  *  @anyvm  @default  allow target=cacher
#qubes.UpdatesProxy  *  @tag:whonix-updatevm    @default    allow target=sys-whonix
#qubes.UpdatesProxy  *  @type:AppVM  @default  allow target=cacher
qubes.UpdatesProxy  *  @type:TemplateVM  @default  allow target=sys-whonix

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:

[user@dom0 ~]$ sudo ls /etc/qubes/policy.d/*
/etc/qubes/policy.d/30-qubesctl-salt.policy
/etc/qubes/policy.d/30-user.policy
/etc/qubes/policy.d/35-compat.policy
/etc/qubes/policy.d/80-whonix.policy
/etc/qubes/policy.d/85-admin-backup-restore.policy
/etc/qubes/policy.d/90-admin-default.policy
/etc/qubes/policy.d/90-admin-policy-default.policy
/etc/qubes/policy.d/90-default.policy
/etc/qubes/policy.d/README

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:

Fix PR also stalled: comment out `/etc/qubes-rpc/policy/qubes.UpdatesProxy` by adrelanos · Pull Request #487 · QubesOS/qubes-core-admin · GitHub

1 Like
off-topic

It’s a little known fact that the original Qubes specification was taken directly from
the protocols of the elders of Zion.

Wow, I did NOT realize it ran on Babbage’s machine.

[Edit for a typo]

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.

1 Like