Extra templateVM for email / vault?

[qun]

Hey,

does it make sense to build an extra templateVM for (for example) emailVM or vaultVM?

Or is it no real problem, if I surf with untrustedVM, get mails with emailVM, which have all the same templateVM as vault, personal and so on?

Best regards
qun

[TheGardner]

If you run all in an untrusted VM, this shouldn’t be much different to the behaviour some/most of us did 10 or 15 years ago.
Qubes was build for such paranoid ones of us, who driving every little thing in an own AppVM.

In other words: if you’re feeling fine in surfing + getting mails in the same VM - no problem. But thats a thing, you also can do on any other OS.
For your other question: it never is a real problem, having different qubes (for vault, mails, surfing and work) from the same templateVM.
The thing behind is - you’re using all on different AppVMs and this is much saver. That these AppVMs were children of their parent/templateVMs, doesn’t matter in this case - the childs won’t harm each other.

[qun]

I don’t want to run everythin in an untrusted VM. The question is about splitting not only the VMs, but ALSO the templateVMs. For example:

emailVM - templateVM-email
untrusted - templateVM-untrusted
personal - templateVM
vault - templateVM
shopping - templateVM

Or just having it all email / untrusted / personal /vault / shopping related to ONE templateVM

So, do an appVM can break through via the templateVM to another appVM or can these children really don’t harm each other?

[fsflover]

Some people definitely do that for a better compartmentalization. Also, consider minimal templates, too.

@Sven

There are some folks however who do see the advantage in running things
as compartmentalized as possible. For example: should I ever
accidentally attempt to open a PDF in my mail qube, nothing bad can
happen because there is nothing installed that could open it.

I strive to come as close as workable to a 1 qube per app/domain,
because that is obviously safer. What’s not there can’t be exploited or
exfiltrated or even shared/leaked by mistake.

[fsflover]

@qun

So, do an appVM can break through via the templateVM to another appVM or can these children really don’t harm each other?

TemplateVM provides the root partition to the AppVM. Every reboot AppVM sees that the root partition is reset. So even if it tries to modify it, it will only be seen by this VM and only until reboot. Other AppVMs will not notice that. So no, the children cannot harm each other. More information: Templates | Qubes OS.

[qun]

ah, ok, thank you!
So the only security advantage to make nearly one templateVM for each appVM (maby better 3 districts which one template for different VMs: very safe / safe / not safe) is not to break the appVM itself, by opening for example PDF in the emailVM, isn’t it?

I considered the minimal templates for the sys-net and sys-firewall. But for that I must understand, what do I need for these Qubes and what is in the minimal template. But maby I will understand it there: Minimal templates | Qubes OS

Maby it would be “nice to have” feature, if the Qubes team can make such special templates for special porposes. For example just a template, that can manage sys-net and sys-firewall and NOTHING more. Or a template, that just can manage to get emails via thunderbird and nothing more… and so on. Just some standard cases. That would push the usability for non skilled users.

[fsflover]

@qun

So the only security advantage to make nearly one templateVM for each appVM (maby better 3 districts which one template for different VMs: very safe / safe / not safe) is not to break the appVM itself, by opening for example PDF in the emailVM, isn’t it?

Another advantage is that the less software you have installed, the less attack surface you have in general. Yet another advantage is that if your template is somehow compromised/broken, it will affect less AppVMs (ideally, only one). Compartmentalization to the limit!

@qun

Maby it would be “nice to have” feature, if the Qubes team can make such special templates for special porposes.

This is an advanced feature that only experienced users would benefit from. At the same time it could confuse new users. Qubes already has a steep learning curve and a lot of VMs by default. Advanced users can install the minimal templates following the guide you linked (and ask for help here!).

[qun]

@fsflover

Another advantage is that the less software you have installed, the less attack surface you have in general. Yet another advantage is that if your template is somehow compromised/broken, it will affect less AppVM (ideally, only one). Compartmentalization to the limit!

ok… and what is the (security) difference, if I make just stanaloneVMs for nearly everything instead of making templateVMs and appVMs for each “task”? Is the benefit especially in separation from the root partition which is in the templateVM?

@fsflover

This is an advanced feature that only only experienced users would benefit from. At the same time it could confuse new users. Qubes alrady has a steep learning curve and a lot of VMs by default. Advanced users can install the minimal templates following the guide you linked (and ask for help here!).

ok, sounds comprehensible

[fsflover]

@qun

what is the (security) difference, if I make just stanaloneVMs for nearly everything instead of making templateVMs and appVMs for each “task”? Is the benefit especially in separation from the root partition which is in the templateVM?

Yes, the reset of root partition is the main advantage in security. This brings more security through isolation. Software in the AppVM will not be able to change the root partition. It also bring a lot of convenience with updates, software installations, less disk space, lower number of VMs.

See also:

How do I create a standalone VM?

@bill actually, installing a non-native VM for this purpose is loosing out on a lot of Qubes features. security-wise you’ll be running that qube in the HVM virtualization mode which the docs state has security disadvantages compared to standard qubes VMs (which run in PHV mode) convenience-wise You’ll be missing on automated updates (through Qubes Updates); you’ll be seeing the desktop of that VM instead of a seamless experience where the windows integrate well with everything else, etc. …

[qun]

ok, sounds great! I use Qubes already for many years, but as a not very advanced user it has tons of things to learn

So, will try to “build” templates for each purposes and kill all standalones (except windows)