How-to use a custom qube proxy update

Introduction

This guide will explain how to change the update proxy qube that is used when updating templates, this may be useful if you want to download your updates through a VPN or a qube with some caching.

Explanations

The default update proxy is defined in /etc/qubes/policy.d/90-default.policy in dom0, it defaults to sys-whonix for qubes tagged whonix (which are tor qubes), otherwise it’s sys-net for all other templates.

Setup in Qubes OS .42 with the GUI

It’s became easy to change the update proxy settings thanks to the new GUI. You can choose the default update proxy and also add exceptions, and you make sure you won’t break anything :+1:

Setup using command line

In this example, we will use a qube named sys-vpn as a proxy for the templates VMs:

Dom0

In dom0, edit the file /etc/qubes/policy.d/30-user.policy (it shouldn’t exist by default), it will override the default settings, add the following content to the file. Note that the Whonix lines are required if you plan to use whonix (qubes with tor).

# Upgrade Whonix TemplateVMs through 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

# Your custom UpdateProxy
qubes.UpdatesProxy      *   @type:TemplateVM        @default    allow target=sys-vpn

sys-vpn qube

In the settings of sys-vpn qube, go to the Services tab, in the drop down list select qubes-updates-proxy and then click on the [+ Add] button.

Restart the qube, done!

8 Likes

Should I create the file /etc/qubes/policy.d/30-user.policy if it doesn’t exist ?

absolutely, if you edit an existing file, your changes may be lost in an update.

I updated the guide to make this clearer.

Few comments:

  1. No need to edit/create the file as root - you can do this as standard
    user.
  2. You can use any policy file with a lower numbering than 90 - if you
    like you can use 10-updates.policy or similar, to make it easy to find
    the updates rules.
  3. Most important you must copy the Whonix rules out of
    90-default.policy in to your new policy file:
# Upgrade Whonix TemplateVMs through 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

Put these lines above your new rule.
This is because policy processing stops at the first match.
If you do not have the Whonix rules above your custom rule then policy
will match the Whonix templates (@type:TemplateVM) and direct updates to your custom
target. This is almost certainly not what you want.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
1 Like

Thanks, I’ll update the guide!

I used /etc/qubes/policy.d/30-user.policy because that’s the file recommended in the README in that directory, and I had to pick some file for the guide to make the instructions easier.

So, I presume, since it will match the first rule, if you have set the whonix-updatevm rules above the sys-vpn rule, you don’t have to delete those lines in your 90-default.policy ?

I updated the guide, the new file should look like this:

# Upgrade Whonix TemplateVMs through 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

# Your custom UpdateProxy
qubes.UpdatesProxy      *   @type:TemplateVM        @default    allow target=sys-vpn

You dont need to, and you should not.
Keeping the existing default rules allows you to quickly roll back to
the default settings, simply by removing or commenting out your custom
rules.

I’d add that in case of a Qubes OS update, when you edit a system file, you have no guarantee your changes won’t be overwritten any time soon.

That’s why the files here are numbered, this allow users to inject user-defined files before/after system files, and you have a guarantee that your file won’t be overwritten by an update.

I added the updates-proxy-setup service to my qube, which has no network. What is the correct way to write 30-default.policy? (a little confused).
1 option:

# Upgrade Whonix TemplateVMs through 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

# Your custom UpdateProxy
qubes.UpdatesProxy      *   @type:TemplateVM        @default    allow target=sys-net

qubes.UpdatesProxy      *   Myqube       @default    allow target=sys-net
qubes.UpdatesProxy.     *   @anyvm      @anyvm    deny

Or simply:

qubes.UpdatesProxy      *   Myqube       @default    allow target=sys-net

This should be enabled in the target qube offering the proxy, not in the qubes using the proxy

The Option 1 rule seems fine to me.

This service listens on 127.0.0.1:8082, and routes traffic through qrexec to tinyproxy , and configures dnf to use this proxy.


Do I understand correctly that if I add in 30-user.policy only:

qubes.UpdatesProxy      *   Myqube       @default    allow target=sys-net

, then all other policies starting with “qubes.UpdatesProxy” will stop working? I.e. every time I add an additional policy to a required service, all existing policies in 90-default.policy must be listed in 30-user.policy, otherwise they are completely rewritten?

After reading qubes documentation (How to install software | Qubes OS), I was under the impression that the file /etc/qubes-rpc/policy/qubes.UpdatesProxy has to be modified to modify update proxy. Is it not the recommended method to update proxy?

What’ll happen if someone updates file in this guide( /etc/qubes/policy.d/30-user.policy) as well us the file referred in this reply?

It is deprecated and has been moved to /etc/qubes/policy.d/90-default.policy. It still works for compatibility reasons, but is no longer the recommended way.
If you are using Qubes 4.2, editing the “Updates” part of the global settings will create a new 50-config-updates.policy file with the desired settings.

If you create another 30-user.policy file, it will be used instead of the others, so make sure you know what you are doing with it.

1 Like

If you update the system files in-place, you may risk to lose the changes upon a package update. The new file is the recommend way to proceed as explained in the original file comment.

1 Like

I just found in 4.2 there is a GUI to manage the Update proxy :+1:

2 Likes

And there’s also a GUI tool for policy editing, which I find much more practical than vim :slight_smile:

1 Like