Is it normal that templates get updates directly from sys-net?

User Support General
1

I ran “sudo dnf update” in Qubes 4.1 in a console of a fedora template and noticed that it only starts the qube sys-net but not sys-firewall. Consequently, the updates are obtained directly from sys-net.

Is this normal behavior or is something wrong?

2

Nope! You probably have set sys-net as updateVM in your “General Settings” in Qubes Manager.

1 Like
3

No, in Qubes Global Settings I have set as net qube “sys-firewall”, as dom0 update qube also “sys-firewall” and as clock qube “sys-net”. Where do you think the error is?

4

Hmm, then it could be normal, that you see ‘sys-net’ entries in your logs…
What if you change the updateVM to sys-whonix ? Or can’t you set that, because you don’t have the whonix’es installed…?

5

It’s normal.

6

Thanks! What’s the reasoning behind this? Isn’t sys-firewall much more trusted than sys-net?

7

Even if you configure something else instead of sys-net (or sys-whonix) as the updates proxy VM, its traffic still has to pass through sys-net (or sys-whonix, respectively)… The main difference appears to be that the updates proxy VM knows

  1. some download connection is definitely related to an update;
  2. the name of the template, e.g. fedora-35-my-interesting-clone.

I’m not too worried about (1) but (2) is awkward, so I use a dedicated named DisposableVM as the qubes.UpdatesProxy policy target. (Whatever qube is used for that also needs to have the qubes-updates-proxy service enabled.)

1 Like
8

Update proxy is running in sys-net, as far as I know (you can check it in /etc/qubes-rpc/policy/qubes.UpdatesProxy), and communication between template and sys-net is done via RPC/qrexec, which is absolutely safe.

9

Update proxy is running in sys-net, as far as I know (you can check it in /etc/qubes-rpc/policy/qubes.UpdatesProxy ),

No, in /etc/qubes-rpc/policy/qubes.UpdatesProxy it doesn’t say anything about sys-net for me, only about sys-whonix, although Qubes updates are not done via Tor network.

10

Dear rustybird,

could you explain what settings to change if you want the updates to be routed through a named dvm instead of directly through sys-net? Thanks a lot!

11

… or sys-whonix, or any other netVM.

So you set sys-fitrewal in Global settings, in update proxy is sys-wnonix, and only sys-net is started?

Are you sure you are getting updates, actually? What is the output of dnf update?

12

Here the output of “sudo dnf update” in fedora-34:

Fedora 34 - x86_64 - Updates 15 kB/s | 16 kB
Fedora 34 - x86_64 - Updates 92 kB/s | 3.4 MB
Qubes OS Repository for VM (updates) 42 B/s | 833 B
Dependencies resolved.
================================================================================
Package Architecture Version Repository Size
================================================================================
Upgrading:
xxx x86_64 xxx.fc34 updates xxx k
Transaction Summary
================================================================================
Upgrade 1 Package

And the output of “sudo apt-get update” in debian-11:

sudo apt-get update
Hit:1 Index of /r4.1/vm/ bullseye InRelease
Hit:2 Index of /debian bullseye InRelease
Get:3 Index of /debian-security bullseye-security InRelease [44.1 kB]
Get:4 Index of /debian-security bullseye-security/main amd64 Packages [120 kB]
Fetched 164 kB in 6s (26.0 kB/s)
Reading package lists… Done

13

Can you please copy/paste content of your /etc/qubes-rpc/policy/qubes.UpdatesProxy here?

14

I could bet that the first line in there is

$type:TemplateVM $default allow,target=sys-net

and your statement directly from sys-net would still be wrong. It’s not directly, as I pointed out. Template gets its updates from sys-net via RPC/qrexec. Directly would be if you’d set sys-net as netVm for a template, which is exactly what one wouldn’t want to do.

Why would you expect your updates come from sys-firewall if it’s not set in qubes.UpdatesProxy and why do you think it would be safer if it comes from sys-firewall (again - not “directly” but via RPC/qrexec)?

How do you now this if

$type:TemplateVM $default allow,target=sys-whonix

is set in qubes.UpdatesProxy?

15

Here ist the output of “/etc/qubes-rpc/policy/qubes.UpdatesProxy”:

$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny

16

?

17

I think it’s not over the Tor network because neither sys-whonix nor sys-firewall start when I run “sudo apt-get update” or “sudo dnf update” respectively in fedora-34 or debian-11. But an internet connection seems to exist, because the commands work.

18

True - but you have not provided any reason to suppose that this wont
happen.
The lines you quoted show that templates tagged with whonix-updatevm
will use sys-whonix. Nothing more.

In 4.1 the policy files have changed.
This has been covered in other threads, and pointed to by rustybird.
Look at /etc/qubes/policy.d/90-default.policy, where you will find the
default target to be sys-net.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes
19

Thanks, that was my next hint to check.

20

Thank you, unman, now I understand.

It is the following line in /etc/qubes/policy.d/90-default.policy which you could change:

Default rule for all TemplateVMs - direct the connection to sys-net
qubes.UpdatesProxy * @type:TemplateVM @default allow target=sys-net