TL;DR: There are often trade-offs involved in setting up your system and workflows in one way or another, and a setup that’s right for me might not be right for you. I’ve found that starting by defining my threat model (or risk profile) is a useful way to reduce the number of options I have to consider when making decisions that affect either my system or my workflows and ultimatey decide how much time or convenience I am willing to invest in mitigating a given risk.
The short answer is yes, if you want two (or more) qubes to be isolated from each other, you’ll copy any files and configuration that you want to be present in both. The longer answer is: that doesn’t mean the process has to be tedious and there are a number of ways in which you can make it more manageable.
For example:
-
You can hold some configuration files in the template and have those be copied automatically as part of the normal appVM operation. (A large portion of the file system of any appVM is copied from its templateVM when the appVM starts, e.g. any file in
/etc. See docs quoted/linked in this post for details.) -
Depending on your use case (e.g. a new customer/client since you mention that) you could have an appVM that is fully configured but that you don’t use directly. When you start working for a new client, you clone that appVM. (And presumably, once the work is done you could destroy that clone to ensure you don’t retain unnecessary client/customer data.) It really depends on your work and needs, but it’s an option that may fit some scenarios.
-
It may also make sense to invest some time automating the creation or configuratiom of some qubes. For example, you may notice that it is possible to create
sys-usbin a semi-automated fashion, by running a single
command. (This is really just an example, but the command is in this section of the docs). Depending on their needs and abilities some folks automate the creation or configuration of qubes in a similar way, using a number of different tools. (That is a whole topic in itself.)
You may have noticed that I keep saying: depending on your use case, depending on your needs, depending on the abilities or time you have… it’s not a coincidence. There is rarely one true way of doing things, and most decisions end up uncovering one or more trade-offs. You’ll often see recommended to start your reflection by listing what you want to protect, from whom, why, and how important that is. (That process is sometimes called creating a threat model or a risk profile.)
Such an exercise is often a good way to determine how much effort (time, storage, appVMs, you name it…) it makes sense for you to dedicate to mitigate which risks. Not everything that someone else does is necessarily useful or desirable for you to do.
As food for thought, since you ask about copying files from one qube to another, notice that the operations that you may want to allow or restrict could end up being direct opposites depending on what you want to protect! For example, the requirements of ensuring the integrity of some data or ensuring its confidentiality typically lead to opposite rules for copying data from one qube/domain//level to another. (The rules around copying data that you’ll find in the Qubes OS docs are typically about ensuring data integrity: “never copy data from a less trusted qube to a more trusted qube” —this post made me realize that— trusted in that case means something along the lines of “I trust this qube doesn’t contain malware”.)
It might sound counter-intuitive, but keeping confidential data in a qube ridden with malware may not be much of a problem if you can ensure such malware cannot get the data out of the qube. That’s very much the principle behind the idea of the so-called “air gap”, and one possible use for a vault qube. (But then you would certainly not copy anything from that vault to, for example, dom0 because data integrity matters a lot in dom0.)
Always keep in mind that you are the one assigning meaning to qubes, colors, etc. You decide which data you store in which qube, and why.
In my experience, reflecting about my goals is how I go from thinking about all the setup I could do if I had an infinite amount of time, to the setup that I will find useful tomorrow morning. Additionally, I’ve found that you’ve got a good chance of getting useful answers in this forum when asking how to achieve a specific goal with the tools available in Qubes OS 