Denied: qubes.UpdatesProxy

When trying to update TemplateVM I get this warning, that the connection to the Update Proxy is denied.

My system:

### Qubes Dom0 (Qubes R4.1)
[user@dom0 ~]$ uname -a 
Linux dom0 5.10.8-1.qubes.x86_64 #1 SMP Mon Jan 18 18:24:01 CET 2021 x86_64 x86_64 x86_64 GNU/Linux

### Update VM (sys-whonix)
user@host:~$ uname -a
Linux host 5.4.61-1.qubes.x86_64 #1 SMP Thu Sep 17 01:09:48 UTC 2020 x86_64 GNU/Linux

Anyone else with this issue?

Any specific information that I should provide?


EDIT: Some information:

qubes.UpdatesProxy policy

[user@dom0 ~]$ cat /etc/qubes-rpc/policy/qubes.UpdatesProxy 
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny

qubesctl [...] update.qubes-vm

[user@dom0 ~]$ sudo qubesctl --skip-dom0 --targets=fedora-32 --show-output state.sls update.qubes-vm
fedora-32:
  ----------
            ID: dnf list updates --refresh >/dev/null
      Function: cmd.run
        Result: False
       Comment: Command "dnf list updates --refresh >/dev/null" run
       Started: 22:40:23.101185
      Duration: 3238.605 ms
       Changes:   
                ----------
                pid:
                    1151
                retcode:
                    1
                stderr:
                    Errors during downloading metadata for repository 'fedora-cisco-openh264':
                      - Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64 [Recv failure: Connection reset by peer]
                    Error: Failed to download metadata for repo 'fedora-cisco-openh264': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64 [Recv failure: Connection reset by peer]
                    Errors during downloading metadata for repository 'fedora-modular':
                      - Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64 [Recv failure: Connection reset by peer]
                    Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64 [Recv failure: Connection reset by peer]
                stdout:
  ----------
            ID: update
      Function: pkg.uptodate
        Result: True
       Comment: System is already up-to-date
       Started: 22:40:29.468223
      Duration: 2599.923 ms
       Changes:   
  ----------
            ID: notify-updates
      Function: cmd.run
          Name: /usr/lib/qubes/upgrades-status-notify
        Result: False
       Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
       Started: 22:40:32.068342
      Duration: 1361.085 ms
       Changes:   
                ----------
                pid:
                    1306
                retcode:
                    1
                stderr:
                stdout:
  
  Summary for fedora-32
  ------------
  Succeeded: 1 (changed=2)
  Failed:    2
  ------------
  Total states run:     3
  Total run time:   7.200 s

Still no real clue why this might be happening.

1 Like

Did you ever figure this out? Im getting this all day.

OP’s UpdateProxy policy is missing rules for non-Whonix VMs. The rules say that any VMs with tag whonix-updateVM would use sys-whonix as their UpdateVM, but there are no rules that would match other templates that don’t have that tag.

Assuming you want to update the other templates using sys-net, two more lines could be added:

@type:template @default allow,target=sys-net
@anyvm @anyvm deny

This is explained in more detail here: How to install software | Qubes OS

1 Like

This isn’t right in 4.1.
The policy file framework has been updated to use a default unified file
under /etc/qubes/policy.d/90-default.policy.
If you want to make changes to the default policy, you create a NEW
policy file in that directory, numerically lower, and that will override
the default.
That separate Whonix file is unnecessary, since it is using the old,
deprecated, form, which will be used under 4.X, but dropped in 5.0. Whonix
treatment is correctly set in the default file.

SO, to anyone having this problem, let’s get some hard information:

  1. Confirm which version of Qubes you are using.
  2. Does the error affect all templates? If not, which are affected?
  3. For templates which show the error, what is the output of qvm-tags?
  4. Are you updating over Whonix?
  5. Have you made any changes to default policy?
  6. What template are you using for the UpdateProxy - by default this
    will be sys-net unless you opted to update all templates over Tor.
1 Like