Sudo apt update starting/using default sys-net

User Support
#1

When running sudo apt update in a debian template it uses sys-net.

Or in my case attempts to use it. I’m using a different vm for networking so it starts up sys-net instead. I’d rather this use my sys-vpn (which is connected to firewall > sys-net2) and is added as a netvm to the debian template

For some reason running this command starts a sys-net vm. This means sys-net can be made to run from within a different vm.

It also may mean that if I was allowing traffic through sys-net traffic can flow through this despite me not allowing it to do so.

Qubes vm update also fails with

Invalid response from proxy: HTTP/1.0 500 Unable to connect  Server

I’ve also set mt dom0 update vm to use sys-vpn

Anyone know why this happens and is it a security risk?

#2

Can you paste here the content of /etc/qubes-rpc/policy/qubes.UpdatesProxy (in dom0)?

#3

This file doesn’t exist, I can see ClipboardPaste, InputTablet, GatewayCommand and more files but no .UpdatesProxy or anything like that @DVM

#4

Try to do the following in dom0:

  • sudo nano /etc/qubes-rpc/policy/qubes.UpdatesProxy
  • Paste the following in it, save and exit:
    $type:TemplateVM $default allow,target=sys-vpn
  • sudo chown root.qubes /etc/qubes-rpc/policy/qubes.UpdatesProxy
  • Open sys-vpn settings, click on Services and add qubes-updates-proxy
  • Restart sys-vpn

Try to update a template again and see if it works.

1 Like
#5

Works fine now, ty! Not sure, why this isn’t the default, when I think about it I must have used/been using sys-net many times when I updated before as I was using the default sys-net. Is this a risk?

#6

If you were using sys-net before, it means it’s possible you used your real IP address to upgrade packages. I don’t think it’s an issue unless you really don’t want your ISP to know you are using Qubes OS.

Also, to follow Qubes OS idea, you could create a dedicated AppVM named sys-upgrade for example and replace sys-vpn by it. It means only this VM will be used to upgrade and not sys-vpn directly. Set its netvm to sys-vpn and you are good (everything will go trough the vpn).

#7

There’s no possibility of a MITM attack?

#8

All repos should use https on Fedora and Debian, so you have nothing to worry about.

#9

Ok ty

#10

Also, all packages are signed by Qubes key, and in Debian the
repositories are signed. (Not sure of current status of signed Fedora
repositories.)

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

It would be great if there could be a setting to set this in qubes global settings, to force all update checks and updates through the vpn. I know dom0 updates can be set to go through a vpn.

I was operating under the assumption all my traffic is going through the vpn probably others are too so might make it easier

#12

It’s not clear, but if you use Qubes 4.1 you should use /etc/qubes/policy.d/90-default.policy

Although old policy format will still be supported until at least Qubes 5.0, you should consider to start to use it already now keeping in mind it would most probably enable easier transition to 5.0