Such a thing as too many templates? Looking for advice

Hello every one, I just installed Qubes and I love it. I am currently in the process of organizing my Qubes, and I’m also currently researching on this topic, including on the documents site, and old old2 posts. I have a few questions.

Vaults

In the old2 post, @unman says the following:

I have a number of vaults - most have data generated internally, or
transferred from non Qubes systems, using qvm-block. For these I have
policies that prohibit write access from other qubes, and limit qubes to
which data can be transferred.

As I have said, I don’t care if I am storing
malware infected files. All files are opened in offline disposables.
If I need to use a file or share it, then I use qvm-convert to produce
relatively clean copies.

This makes a lot of sense to me, so I am trying to do something similar with multiple vaults. I have cloned the template vault right after installing ( so before storing any files on it ) for all my needs, which amounts to 8 vault qubes. I have also cloned a template for each of them, to ensure that they do not share a template, because about 50% of them will have their own applications installed, so my logic was to minimize the possibility of the template being compromised if the app is. Is having a separate template for each sensible or not? Combined with other templates, it makes my template count exceed 40 (not including appvms or servicevms). Should I change my approach, and if so, how?

DVMs

I have also cloned the default DVM for each of my needs, and cloned a separate template for each. My reasoning was the same, I need separate programs for each of these tasks, so I shouldn’t use the same template. I also had some DVMs with same programs but different identities.

Since I have a lot of these DVMs and most of them have their own template, my total template number ends up being around 40 once all other templates are taken into account (since DVMs are also counted as templates). Is this a fundamental flaw in how I am organizing my qubes? Is this insecure and am I making myself more open to attacks than I would be with less? Is there such a thing as too many templates from a security perspective?

2 Likes

I don’t see a problem, as long as:

  • you don’t get lost and confuse your templates (and “disposable templates”?)
  • you don’t take too much time to upgrade them
  • you don’t lose your time doing this instead of more efficient solutions (strict policies, etc).

Except that:

If the remaining 50% has no customization that might lower how much do you trust them, you can share the same template.

Same here: if the disposable template has no customization, you might want to use the same disposables for different identities.

Side note on markup

Welcome here! Next time you can just paste an URL and the forum engine will automatically retrieve the topic title. It will be easier to understand the link purpose.

1 Like

Thanks for reccomendation. Can you give suggestions for what I can do? What are strict policies? Can I read about the suggested ones somewhere?

How much is too much time?

Even if its random pictures and files and personal pictures in the same vault? Random pictures and files from the internet (memes, documents) along with my personal pictures?

Does not doing this adds another layer of security though?

Got it.

1 Like

Not really… BUT:

It’s also not gives you what you think you get from such ‘method’

An AppVM (qube) can’t really compromise it’s template in practice, so I don’t see the point having separate templates - unless it’s a different distro, and/or minimal/normal

You say they use different applications…

well that 100+ packages which needs to be there just to provide the basic OS are surely not different :slight_smile:

And those very few that might be not needed on one or two qubes, doesn’t spoil the rest… as they are just sitting there.

Also one of the main point of having template based VM’s tat you only need to update the templates… I can’t imagine what a nightmare would be to just update those 40+ templates. Not even mentioning the unnecessary space requirements they have.

2 Likes

No, but there is such a thing as too many latent packages installed in each template from a security perspective.

1 Like

In practice?

I am currently looking into minimal qubes. I would like to replace the crucial qubes like my vaults with minimal templates, but I haven’t found anything about vaults based on minimal templates on Minimal templates — Qubes OS Documentation

But aren’t they harder to be exploited since they are just standard OS packages instead of random applications?

Do you mean that since they are never launched, they can’t exploit the template?

Makes sense. Should I then do per identity rather than app? I’m kind of stuck on figuring on figuring out how to do this, any suggestions are welcome.

So do you mean that I’m correct in not installing a bunch of applications on the same template and that he is wrong when he says:

2 Likes

Or do you mean that I’m wrong by installing a bunch of templates?

1 Like

Do you mean that since they are never launched, they can’t exploit the template?

Well, there are mutiple topics about this, and there is no single good answer.

My personal opinion is:

  • the template can’t be compromised from an AppVM, not even if it’s compromised.
  • the apps sitting (but not running) in the template does not reduce the security of a qube based on this template.

If you assume your qube is compromised by any means, then the extra packages might - or might not - give the ‘intruder’ some benefits. However if it can reach the internet - which usually the case in practice - then the attacker can download anything they want. So it makes no difference if those extra apps are there by default or not.

Any package you might say: ‘easy to compromise’ it is only create risk if you use it.

But that’s leads to another - more important - question/problem about trusinting the OS repositories…

Minimal templates has advantages, but not becase they are more secure, but because requires much less maintenance/upgrade. - if you ask me.

If you assume/accept that a compromised qube can compromise your whole Qubes OS, then… seprate templates are still not helping in this situaion. If it is really happens in practice, then it’s “Game Over” anyway. (And you might need to replace your hardware too)

2 Likes

How many templatevms and appvms do you have?

1 Like

I have only a very few:

  • fedora-latest - for all (~20) my ‘normal’ AppVMs, including dvms
  • fedora-minimal-latest - for VPN/proxy qubes (~5)
  • debian-minmal-latest - for sys-net ‘type’ qubes (2)

+ if my clients/employer requires it’s own template, then I have those as separate templates, but here the reason is those are using internal repositories, instead of the public ones…

2 Likes

I’m currently writing something for the docs about this. You can take a look at the preview (it hasnt been reviewed!). It is based on this community guide:

Restricting internet access is also a good option.

If you ask this question, that might mean that you already spend too much time on creating your templates instead of using more meaningful features of Qubes OS.

It is too much when your template is not supported anymore.

Unless you store that in your template, it could be an issue at the app qube level. Or not, depending on how you use your qube.

Same thing here, if maintaining such a complex system prevents you from investing your time in better options, it might be a problem.

Do not use minimal templates, blah blah blah…

1 Like

True that.

No one would disagree on the first point. Many disagree on the
second. This is an area where users have to come to their own informed
conclusions.

On the feasibility of updating multiple templates, on this machine
I have 28 templates, on others more. Updating is just the same as with
2 templates. I use a caching proxy to save time and bandwidth, and the
Qubes Update tool works in just the same way.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

2 Likes

My understanding of a vault is something that stores important data and does nothing more than file management (copy, rename, delete), i.e. a very minimal non-networked system - one template for all vaults.

Cons: if e.g. GNU coreutils has a bug, that would affect all AppVMs. The only way around such issues is to use multiple heterogenous templates - using different OS.

DVMs

It is absolutely fine and correct to store different identities in a disposable template. It is also good not to run apps in disposable templates (just like you don’t in TemplateVMs) and probably even keep them offline. This gives you a better chance for a clean start of your disposables.

Is there such a thing as too many templates from a security perspective?

Cloning the same template provides zero additional security and is a waste of resources. A more complex system also increases administration time and the chances for mistakes.

Besides that, the only anti-security perspective I can think of is potentially decreased anonymity. Example: a user updating 40 templates within a short time is more unique. You can mitigate that by not updating them at the same time or by caching (as @unman mentioned).

2 Likes