how do qubes templates themselves download from the internet when running dnf or apt i see that their netvm is set to default(n/a) i have set up my own mullvad service qube as well as an additional template set to default(n/a) running debian and i created my own firewall that is an appvm that uses my mullvad service qube to then use as a netvm for all my other non-whonix qubes. i have routed everything to this so that when i open a qube and use the internet i am using mullvad. however when i just updated qubes os as well as templates what is it using to download these. i read about a proxy it uses but what is this proxy exactly and what just happened. was my ip exposed to the internet because this is set at default(n/a)? i did also click update through tor/whonix upon installation of qubes does this apply to all templates as well as os updates? i am trying to have all this routed through my mullvad appvm i created that uses my mullvad service qube.
i want to further write that i am in an authoritative country i can not let my isp or government see that i am using tor. i configued bridges through the sys-whonix service through the anon connection wizard but i dont know if they are able to see anything. i am trying to have this all route through this mullvad firewall i created because the tor update is slow as well as i dont want tor or my ip exposed i need it to all appear as mullvad to my isp.
to summarize all this i want my isp to only see mullvad traffic however when using whonix i want the end traffic to show tor. i have checked those in browsers and they worked fine. my main concern is what this update just did. i want to only use my mullvad firewall qube to install these updates or show that traffic to my isp rather i am using dnf or apt or qubes os updates. does anyone else have a set up similar to this?
from what i read here
Technical details
The updates proxy uses RPC/qrexec. The proxy is configured in qrexec policy in dom0: /etc/qubes/policy.d/90-default.policy. By default this is set to sys-net and/or sys-whonix, depending on firstboot choices. This new design allows for templates to be updated even when they are not connected to any NetVM.
if this uses sys-net then it does not inherit anything from any previous firewalls that are set up. so this just routes it through all your exposed ip? how is this not a security flaw.
HTTP proxy for downloading updates
Upgrade all TemplateVMs through sys-whonix.
#qubes.UpdatesProxy * type:TemplateVM default allow target=sys-whonix
Upgrade Whonix TemplateVMs through sys-whonix.
qubes.UpdatesProxy * tag:whonix-updatevm default allow target=sys-whonix
Deny Whonix TemplateVMs using UpdatesProxy of any other VM.
qubes.UpdatesProxy * tag:whonix-updatevm anyvm deny
Default rule for all TemplateVMs - direct the connection to sys-net
qubes.UpdatesProxy * type:TemplateVM default allow target=sys-net
qubes.UpdatesProxy * anyvm anyvm deny
this is what i see when i opened 90-default.policy with nano. is this where i can change it to update with this? how come qubes thought it would be a good idea to just use sys-net by default for updates?
@s were removed because it thought i was tagging
i had changed the target=sys-net and target=sys-whonix to target=(my mullvad qube) id imagine this has fixed it however i am unsure if someone can let me know if theres a way i can test it i tried running curl but it doesnt output anything im not sure how i can see the traffic using this because i am not familiar with dom0
I would not edit 90-default.policy directly for this. Put your override in a lower-numbered local file, for example under /etc/qubes/policy.d/30-user.policy, so package updates do not overwrite it.
Also note that target=your-mullvad-qube only makes sense if that qube actually provides the Qubes updates proxy service. It is not the same thing as setting a template’s NetVM. For dom0 updates, check the global updatevm setting (qubes-prefs updatevm), and for template updates check the qubes.UpdatesProxy policy.
For testing, avoid curl from dom0. Start a template update, then watch traffic/logs in the qube you expect to be the proxy path. A simple check is whether the Mullvad qube sees the outbound repo connections while sys-net only sees Mullvad VPN traffic. If sys-net still opens repo connections directly, the policy/path is not doing what you want.
More details here:
If you use the GUI from Qubes Tools → Qubes Global Config → Updates → Update Proxy
these issues will be solved for you. (Policy file numbering,
availability of update service)
Remember to also change the dom0 update qube.
i had ended up using this as the solution. it appears all i had to do was click a few buttons. it also seemed all updates were going through sys-whonix. should i change back the 90-user.policy to =sysnet? i still have it set up as my mullvad service qube. if i change it to sys-net it will still go through the update proxy then correct?
i have one more question though. these appear to be updates for fedora debian dom0 whonix what about when i actually run dnf or apt in any of these? what connection is it using to download packages and how can i change that? i am trying to get everything to use my mullvad service qube.
Yes, as already said - it’s inadvisable to change the default policy -
revert any changes you made.
If you use the GUI then settings will be made in a policy file that
overrides the default - policies are processed in numeric order and
processing stops at a match.
Look in /etc/qubes/policy.d/50-config-updates.policy
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.