Nope! You probably have set sys-net as updateVM in your “General Settings” in Qubes Manager.
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?
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…?
Thanks! What’s the reasoning behind this? Isn’t sys-firewall much more trusted than sys-net?
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
- some download connection is definitely related to an update;
- 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.)
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.
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.
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!
… 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?
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
Can you please copy/paste content of your /etc/qubes-rpc/policy/qubes.UpdatesProxy
here?
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
?
Here ist the output of “/etc/qubes-rpc/policy/qubes.UpdatesProxy”:
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny
?
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.
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.
When I comment in the Forum or in the mailing lists I speak for myself.
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
The advice is not to change that line in the default file, but to keep
that file unchanged, and create a lower numbered file containing
user modifications.