in my Debian template, it installs chromium on all my VMs based on that template. But how does that work, when the template actually does not has internet access? Shouldnt it refuse the command?
Also, what is the correct way to install applications in VMs based on templates? If I install Signal in the template etc, it install on all my Debian VMs. Isn’t there an safer way, to only having applications installed in some VMs and not others? For me, it looks like it just increases attack surface to have all applications in all VMs.
sudo apt install -y chromium
in my Debian template, it installs chromium on all my VMs based on that template. But how does that work, when the template actually does not has internet access? Shouldnt it refuse the command?
While the template VMs have no “network” access by default, they do have
access to a proxy which allows updates to take place. This gets
tunnelled through qrexec and into the VM configured as your “update VM”
in Qubes global prefs. So effectively, they do have internet access,
just limited.
Also, what is the correct way to install applications in VMs based on templates? If I install Signal in the template etc, it install on all my Debian VMs. Isn’t there an safer way, to only having applications installed in some VMs and not others? For me, it looks like it just increases attack surface to have all applications in all VMs.
Installing it in the template is the correct way. The two alternatives
to lock this down further are:
If available (eg python packages) install as a user in the AppVM.
This should install somewhere under “~/.local/” and persist through
reboots.
Clone and use specific templates for less trusted software or create
a standalone VM which has a persistent root for that application.
when you do an update (deb: sudo apt update) what really happens is that qubes has configured the package manager (apt, dnf/yum) to use a proxy server insetad of trying to just reach out to the internet from the netvm.
the proxy server is localhost:8082, which is internal to the templatevm. this port is being serviced by the qubes-updates-proxy-forwarder, and all this service does is make an rpc call to dom0, who then forwards it to the right target vm.
if you selected whonix as updatevm at install, the rpc call for UpdatesProxy will get forwarded to sys-whonix, which uses tor to get the updates.
if you didnt selct whonix as updatevm, it gets forwarded to sys-net.
If an attacker wanted to modify templates to gain persistence, would this proxy link between the update VM (which is typically unfirewalled) and the templates be a vector? I remember reading in the man pages of qvm-service that qubes-update-proxy “shouldn’t be used as leak control (pretty easy to bypass)”, if it’s relevant at all.
The update-proxy can be firewalled (and used to be restricted to
appropriate mirrors.) You could reinstate this if you wished.
Simply having a proxy there doesn’t open an obvious attack, since the
attack would have to go from updateVM to Template - the package handing
in the Template should mitigate most issues.