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?
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).
On the contrary, it’s useful to be here, because there will be others with the very same dilemma.
Btw, (at least fedora and debian based) standalones can be updated over qrexec. I have working examples.
I have to finish my minimal debian template script first. I have already spent so many weekends on it (1000+ lines). I also learnt so much Qubes / Linux / Bash coding, … apt keys … but it is a very tough route to go.