If you take an advanced threat model (I can’t really break down exactly what but a nation state adversary with a library of 0days etc.), I’m curious about whether there is value in isolating template VM’s. As in whether there is some conceivable risk in making two AppVM’s based on the same templateVM that in your mind hold different risk between them in terms of external exposure to your threat.
I understand why a templateVM is not affected by actions within an AppVM, but is there some value in cloning and compartmentalizing template VM’s in the face on an advanced threat that doesn’t necessarily concede that there would need to be a hypervisor escape vulnerability that would compromise Dom0 & render the whole exercise useless?
I’ve been trying to duplicate templatevm’s for various activities but I’m unsure of whether this is just wasting space.
The rationale for duplicating templates is not protecting the template from tampering but rather fine-tailoring VM purpose to reduce the attack surface. If templates are similar, it is quite useless.
The value I see in making separate templates is when I need something very specific that is riskier or needs higher security, and the default template cannot do it. Usually the software I want to use is less mature and more experimental, needs a modification to the template to work, or uses a third party repo. I’m mainly trying to limit the risk of exploits that need multiple vulnerable applications to work
I2P - Less mature than Tor. There’s no out-of-the-box setup on par with Tor Browser, TAILS, or Whonix. I don’t want any unnecessary applications that might not respect proxy settings.
USB - Interfacing with hardware is risky due to all the firmware, but I also have some packages installed here that need direct access to hardware and file systems on removable storage. Also Veracyrpt, which needs passwordless root to work
Chrome - This is the only browser that really works with Google and I need to save things from my account so I can delete it.
Moby/Docker - The template needs a service enabled as well as the user added to another group to work.
There’s a huge downside to having a lot of templates. They take up a lot of space, make backups bigger and more time consuming to make, and will suck up a lot of maintenance time. I used to have a lot more, but they were too much of a time suck and made it too hard to get anything done.
Almost certainly not. Either the system is providing the expected security guarantees (at which point there’s no risk in sharing template VMs), or the security boundaries have been violated, at which point a suitably advanced attacker (which you’re assuming here) can do whatever they want. It’s just a matter of how annoying you want to be to them - but “annoying someone who can wield Xen 0days” doesn’t stop them from doing what they want.
The only potential advantages would be, as noted above, customizing software to reduce what’s available for exploit in a VM, but given the Qubes model of “Once you’re executing in an AppVM, you have access to everything in that AppVM,” I’m not sure what you really gain. It feels a bit like the “Ah hah, I’ll foil attackers by not installing a compiler on my server!” stuff from the late 90s/early 2000s that rapidly fell by the wayside - it just doesn’t offer any meaningful friction to all but the least skilled attackers.
Completely agree that faced with a substantially advanced adversary,
templates are no defence. The truth is that against a “nation state
adversary with a library of 0days” nothing is going to help you. You
should prepare on that basis.
This is where a serious risk assessment is essential. Even if you are up
against the state, this does not mean that the full force of the state
will be used against you. “The state” is not some monolithic entity, and
different arms have access to different tools.
Few people are in that sort of situation.
For them, differentiating templates can help by reducing the attack
surface. I completely disagree with @Syonyk in this case.
There’s another benefit that isn’t often mentioned - this is that it
helps to keep your qube fingerprint separate in different activities. I
recommend using different distros and custom templates for this case.
On the downside, if you are using more than a few templates, you should
be using a caching proxy - I use apt-cacher-ng, packaged as an rpm at qubes.3isec.org. It is a drop in replacement for the usual proxy, and
reduces both time and download on updates.
I support systems with many templates, and the maintenance is minimal. The
updates can be run manually, or (better) by cron, and there is minimal
impact on users.
If you are a Fedora fan, and dont use other templates, you might be
better to look for another solution. There can be issues with
fedora updates, particularly with the propagation of update repo across
the mirrors.But if you use a range of templates cacher is good working solution.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
What sort of situations in Qubes does the attack surface, in terms of usermode applications/libraries, really matter? If an attacker can execute code in the AppVM, regardless of libraries or not, they should be assumed to be able to get root, gain ring 0 guest access, and attack the hypervisor from there. I don’t see how “having or not having Spotify installed” changes the relative risk in a VM for an attacker who can be assumed to bring anything they want with them.
That’s certainly a valid use of multiple templates, though.
Backups are almost a non-issue too. If your templates are automatically generated either via script or salt, the only reason to back them up is to save time recreating them if something happens. What you do need to back up in this case is the salt files or scripts themselves. And they probably reside on dom0 (just make sure copies exist in your home directory and do a dom0 backup).
In fact the only qubes I bother backing up (other than dom0) are some AppVMs. Nothing else has persistent data in it. (I don’t bother backing up the cacher even though it’s an AppVM.)
Very interesting. Forgive the ignorance, but what kind of aspects of the template VM’s filesystem that an AppVM assumes gives it a unique fingerprint across multiple AppVM’s?
I understand why something broad like a distro would be a fingerprint, but can you help me understand with some of the smaller details of how a template gives a fingerprint across AppVM’s?
If an application is not selected to be a part of a Qube in QubesSettings but is present within the template, I would assume there is no information about that application passed to the AppVM that hasn’t got it selected, no? My assumption would be there are system configuration elements of a templatevm that are what gives this fingerprint.
Very informative responses thank you to all respondents.
I will look in to the apt-cacher-ng thank you.
My threat-model is more focused on security & LAN threats than fingerprinting for broader anonymity threats, but the point is well taken.