Hello everyone, i started using Qubes OS a few days ago and i spent some time looking for different use cases.
I read the most relevant parts of the official documentation and the forum to find information on the best approaches to install and configure software.
Here follows what I understood so far in terms of security:
Software available in the official repositories and sources should not be installed inside the base template, but inside its clones
Third-Party software, should not be installed directly inside of any template.
The best approach would be to install this software directly inside App Qubes
The installation inside a template can be allowed by temporarily granting network access to it, but it must be tagged as less secure from now on
Software can only be configured inside of App Qubes, as Templates do not copy their home folder content to the Qubes, but just reflects the content of /etc/skel into them
There are several use cases in which users might want to replicate their environments multiple times, without having to reconfigure all programs everytime.
Let’s say that I use the same IDEs and frameworks for my work and personal related projects, the differences in configurations would be so small, that I would highly benefit from a pre-configured template.
I could tweak just the few different settings directly in the qubes.
I personally find some limitations with the default approaches:
The less secure way:
Cloning the base template
Installing official software in the clone
Installing additional software and libraries making the clone less trusted
Creating a “Base-Qube” and configuring all the software
Cloning the “Base-Qube” into multiple Qubes
The safer way:
Cloning the base template
Installing official software in the clone
Creating a “Base-Qube”, installing additional software and configuring it
Cloning the “Base-Qube” into multiple Qubes
The main problems i see with both scenarios are the redundancy of packages and configurations, and the lack of an easy-to-use mechanism to create pre-defined software configurations inside templates.
I apology if I’m missing something, I was wondering which are the best practices in these situations and how expert users decided to overcome these challenges.
I also read an interesting thread here in which nested templates inheritance was mentioned, but it seems complex to accomplish in the near future anyway.
Here it is a quick reference to it: https://forum.qubes-os.org/t/doing-it-wrong-software-installation-theory/23761
Correct. The standard workflow involves cloning a base template (e.g., debian-12-minimal) into a dedicated template like template-development, then installing development tools there. This keeps the base template clean and reusable.
Third-party software must be installed in templates, not AppVMs, because AppVM installations are not persistent. Templates ensure software remains available across reboots and AppVM clones.
Instead of granting templates direct network access, use a proxy:
export all_proxy=http://127.0.0.1:8082
This allows tasks like downloading signing keys or packages via the proxy avoiding the need to grant network access to the template. This reduces security risks that come from accidentally leaving network access enabled after installation.
While configurations like dotfiles are managed in AppVMs, software must be installed in templates.
I am not sure if I understand your approaches correctly. Let’s say you want different qubes for development, e.g. one for python dev and one for web dev, then you have two ways:
Dedicated template for each:
Clone debian-12-minimal to template-python, install packages (e.g. neovim, python3-virtualenvwrapper)
Clone debian-12-minimal to template-web, install packages (e.g. neovim, firefox)
Create AppVMs (e.g. dev-python, dev-web) from these templates.
Con: Redundant installations (e.g. neovim in both templates) → more disk usage
Unified template:
Create template-development with all tools (e.g. neovim, firefox, python3-virtualenvwrapper)
Create AppVMs like dev-python and dev-web from this template.
Con AppVMs inherit unncessary packages (e.g. dev-python would have Firefox installed, dev-web would have python3-virtualenvwrapper) → more bloat inside AppVMs, thus less secure
In relation to this i was thinking about tools like anaconda, flutter, go, cuda libraries etc.
All of them could be installed anywhere in the home folder for example.
And reading the guide on software installations here, i assumed it would have been better not to install any third-party package in the template itself for security reasons.
But yes, i agree that we could do this in the template as well.
This seems extremely useful, thanks.
I haven’t read anything about the local proxy yet.
When it comes to just providing the same tools to App Qubes i see no big problem in your suggestions.
What i meant is that if i use an IDE or a framework that requires heavy configurations or long setups, i don’t want to do that multiple times.
As an example, if we have multiple IDEs like vs codium, configuring them properly potentially requires a lot of time.
How do we manage to set them up only once, and automatically have them configured in each Qube as soon as we create it?
This is my main concern, i see no quick solution to this if not cloning the configured qube n times.
A more simple example could be the configuration of a browser: settings, extensions and preferences.
Is there a way to configure it once, and simply log-in with different accounts on each child Qube without any other manual tweaks?
Unfortunately, not all tools allow exporting settings and configurations easily.
I don’t think that there will be a perfect solution to your problem, you already seem to be aware of the pros and cons. If you end up using the same third-party software in all your AppVM, I don’t think that installing this in the template is a big deal. Some redundancy while using Qubes seems mandatory right now.
I also have an AppVM with software installed in the user space, that I clone to keep my configuration. A clever way would be to use salt to manage configuration changes, installed programs, etc. in each VM and in the /etc/skel of the template. But you need to precisely know what configuration file you need to edit. See:
Hello Another,(great name), welcome to Qubes.
You’ll find that there are differing views on whether to use minimal
templates or not. I use them extensively as base for my templates.
You’ve already been pointed to some issues with your understanding, so I
wont repeat them. I would say that there is almost never need to
grant direct network access to a template. Whether you install third
party software in a template is your choice: there’s no security issue
one way or the other.
The mechanism I use is by salting the qubes. The advantage of this is
that it’s self documenting, it’s easy to rebuild the system, or parts
of it, and to share qubes and configurations with others. (Qubes backup
is not designed for this purpose.)
Clone the base template
Install software to the template, set global configuration, and write
configuration to /etc/skel
Create qube(s) and write any additional configuration to each qube.
This is simple to do - you’ll find examples in shaker
There is little redundancy of configuration here - it’s write once, and
implemented in each qube as they inherit from /etc/skel on
creation.
Salt allows you to use simple declarations to configure templates and
qubes.
If you adopt this approach there is some duplication of packages between
templates - I recommend use of a caching proxy to minimise the impact
of this. There’s one in the shaker, packaged here
If you’d like help with implementing this for a specific case, dont
hesitate to ask.
Hi Unman, thank you very much for your support and hints.
I personally loved the concept of minimal templates as well and I now see things more clearly.
Your approach seems robust and easily scalable.
I’m going to look at the documentation and the examples you provided as they seems really valuable.
I like learning how things work in details and I haven’t read about salting qubes yet.
The caching proxy strategy seems quite interesting as well.
I have to go and get my hands dirty now.
Could it be a good idea to add insights on these strategies here in the docs?
