Best approach to Qubes templates?

Hi all,

I’m trying to wrap my head around the best approach to installing apps in TemplateVM’s.

Is the philosophy of a TemplateVM to only install software from the installed distro’s (that is the distro installed in the TemplateVM) repositories?

According to documentation:

“In order to protect you from performing risky activities in templates, they do not have normal network access by default”

So this is a user safeguard - meaning something put in place to protect me from making a potentially bad decision.

Now say for instance I want to install Brave browser which is not included in Fedoras default repositories. I have two options:

  • I can add the brave repo to the list of allowed repos in my Fedora TemplateVM - I can do this by temporarily enabling network access to the template or I can use the proxy by using export https_proxy=, from there I can use dnf to install Brave

  • I can install brave as a flatpak - I can accomplish this by dnf installing flatpak in a TemplateVM, flatpak is included in fedoras repositories, I can then create an AppVM based on this template and install Brave as a flatpak in an AppVM user the --user flag

Is the more Qubes centric approach option two as I am not polluting a template with something outside of the distros default repos ?

1 Like

Package managers like apt and dnf already use the proxy by default. This means that you don’t need to enable networking for your template (you never need to), since you will be able to download and install packages through this proxy. Add the brave repo and proceed with the normal installation steps.
The only thing that will not work is the key import step, since rpm does not use the proxy. You will have to download it manually and import it like this:

curl -x -LO
sudo rpm --import brave-core.asc

Flatpaks are another way to install applications, depending on how you want to handle them. If I remember correctly, flatpak applications are not updated automatically, so you have to update them manually on each AppVM, which can take a long time depending on how much you use them on your system. You also lose the ability to use the Qubes updater, which updates your packages from the package manager.

My understanding is that this is the philosophy, but it is easy to work around it and install applications from other sources. However, you should generally have some knowledge of the installation process for applications outside of the package repos. For example, .deb packages are essentially file archives with pre- and post-installation scripts. Installing a deb package, at a high level, will:

  1. Run a pre-installation script if there is one.
  2. Extract files into system directories.
  3. Run a post-installation script if there is one.

The risky operations in this case are steps 1 and 3, as arbitrary (and possibly malicious) commands will be executed on your system. Should malicious commands compromise a TemplateVM, then all of the AppVMs and DispVMs that use this TemplateVM will be compromised as well, since they inherit system libraries and binaries from the (now infected) TemplateVM. Step 2 in this case, the extraction process, is much less risky, and so if you examine the contents of your .deb file before installation and notice that there is no pre- or post-installation scripts, then the risk compromising your TemplateVM by installing the application is significantly lower. And, even if the application itself is malicious, so long as you don’t run the application in the TemplateVM, then the TemplateVM won’t be compromised (although any AppVMs or DispVMs will be, but only after you run the application in each of those VMs).

So, moral of the story is that you should be a bit cautious and try to figure out what the installation process is doing before installing any external applications in TemplateVMs. Now, with that being said, the way to install external applications on a TemplateVM from the network is to:

  1. Switch it’s NetVM from none to sys-firewall (or your preferred NetVM)
  2. Install it using the app’s installation instructions.

Note though that you’ll likely need to install with sudo, as many applications will try to install in the $HOME/.local/ directory instead of the /usr/ directory (DispVMs and AppVMs don’t inherit the TemplateVM’s $HOME, so if you install in the wrong location on the TemplateVM then then AppVMs won’t have access to the app).

1 Like

my two cents, the rpm command could directly import using the proxy if using this environment variable to define the proxy

export all_proxy=

Yes, it’s confusing because sometimes it’s all_proxy or http_proxy or https_proxy :roll_eyes:

1 Like

Is it possible, and would it be safer to run a a wget command to import the gpg keys on a DispVM and then copy them to the TemplateVM?

Yes, that’s an alternative you can use instead of using the exposed proxy inside the template. If you feel more comfortable doing it this way, you can do it.

1 Like

By the way, how could a user find themselves compromised when following official instructions from popular software like Librewolf or Mullvad, when adding their repos?

Librewolf’s instructions are pretty straightforward except for the second line where it echo’s and grep’s some stuff. But even then these commands are pretty beginner-friendly.

If the repo I’m adding, and the instructions I’m to follow aren’t from a lesser-known select program, then most people should be good to run them confidently, right? Specially with so little lines like with Librewolf, or are there other methods someone could potentially affect our machines?

Well, you can’t really know for sure if you don’t understand what you’re running from these instructions. Even if you do understand, you still trust that the program you are about to install is not itself malicious.

If you feel it’s safe, you can do it. It’s even better on Qubes because you can compartmentalize everything. Clone the Debian template and install what you need on it. That way, if it turns out to be a bad choice, only the template and the qubes using it are affected, not everything else using the original Debian template.

1 Like