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?
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?
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).
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
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
I worked on three parts in parallel (which is never a good idea). I created a new disposable network … forgot that my testing standaloneVM was set to none network.
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.