What's your Template:AppQube Ratio?

General Discussion
1

This is more of a threat model discussion: I don’t believe there’s a “right” or “wrong” take

On one extreme end, you could install every program within the stock fedora template, and create many app Qubes from it. This has the benefit of limiting storage consumption & keeping your total qubes manageable

On the other extreme end, you could create a dedicated template for every intended app qube. This has the benefit of maximum isolation between installed programs

I tend to lean more towards the latter, closer to 1:1 than 1:2. But I’m curious to hear how others set their system up, and the justification/threat model behind your decisions

4 Likes
2

See also:

My answer:

5 Likes
3

The storage consumption could be limited by the copy-on-write mechanism used by Qubes OS and it is still manageable with the programs dedicated templates.

3 Likes
4

Following dom0 logic: as less as possible packages installed. Why? To reduce attack surface.

3 Likes
5

I’m close to the 1:1 ratio too… with templates derived from minimal templates, providing one app or function. But that would be different if I had other constraints (less memory and/or less disk space available).

3 Likes
6

My AppQube/Template ratio is 4 :

user@dom0:~$ echo $(( $(qvm-ls --class AppVM --raw-list|wc -l) / $(qvm-ls --class TemplateVM --raw-list|grep -v ^bak|wc -l) ))
4
4 Likes
7

Dito.

1 Like
8

Ah, using R4.3 … because qvm-ls does not take “–class” in < R4.3 :slight_smile:

And, to critique your method (in positive spirit) :

  1. you only take the integer part, the ratio may well be 4.99
  2. you count all the Templates and AppVMs; not only the used ones

For me, counting as noted in #1, the ratio is calculated as 1 … while the real ratio is 1.55
But again, that’s for all Templates and AppVMs! Looking at what is usually running, the ratio is almost a perfect 1 (sys-net and a sys-vpn are sharing a “minimal-net” template).

3 Likes
9

If you really want to separate absolutely everything, wouldn’t you be better off creating only standalones instead of a Template-App pair (since I believe you can manually upgrade the standalone like a “regular” system) ?

Personally I don’t really need applications that aren’t included by default in fedora-*-xfce (although I’ve been thinking about switching to the fedora-*-minimal templates and it would change everything), except for maybe LibreOffice (and if I need more specific stuff, I would create standalones), and the benefits of different templates isn’t worth the managing hassle for me personally.

I only have 1 template (stock fedora-*-xfce) that are used for most of my qubes, but 2 standalones : one for programming (cloned from debian-*) since there are a lot of programs I need that come from untrusted sources, and another for a VPN service qube (cloned from fedora-*-xfce).

2 Likes
10

1:1,4 (disp totally ignored)

2 Likes
11

METHODOLOGY:
To compare apples with apples, I propose this counting method, dom0 friendly, no bc or zsh needed:

#!/usr/bin/env bash

calc_and_print () {
        local HEADER="${1-}"

        local nappvms=$( <<< $QVMLS wc -l)
        local ntempls=$( <<< $QVMLS cut -f3 -d'|' | sort -u | wc -l)

        local frac=$((nappvms*100/ntempls))

        printf "%s %1.0f.%02.0f (%d/%d)\n" "$HEADER" $((frac/100)) $((frac%100)) $nappvms $ntempls
}

QVMLS=$(qvm-ls --fields name,class,template --raw-data | grep -E "AppVM|DispVM")
calc_and_print "Total  :"


QVMLS=$(qvm-ls --running --fields name,class,template --raw-data | grep -E "AppVM|DispVM")
calc_and_print "Running:"

My output:

Total  : 1.82 (40/23)
Running: 1.16 (7/6)

I know that I wrote “1.55” earlier… I was not taking into account my named disposables, which are not AppVMs, but DispVMs.

2 Likes
12

I don’t know if mine is right but here is my take, I decided on four templates

  • A fedora (minimal) for passwords and simple documents
  • A fedora (minimal) for email and chats
  • A full suite fedora for ‘office spaces’
  • A full suite fedora for browsing/personas
  • (Also technically a fifth fedora that holds the sys qubes)

I liked this set up because it seems to place similar tools and ‘access’ together. Secure items, minimal tools that only I access locally. Communications that are secure and confirmed. Tools that I need to use for work/productivity. And assumed insecure browsing or entertainment.

Minimal in parentheses because I haven’t done it yet :sloth: but I would prefer them to be, the others can be full for simplicity to get the tools I need in.

2 Likes
13

7 template qubes, 24 AppVMs.

My early approach was to install all I might need in the template (not that much, actually) and then uninstall everything I don’t need in /rw/config/rc.local

Now, I just have a template with emacs, git, podman, and LibreWolf. Don’t even need flatpak, as it turns out.

2 Likes
14

I split my templates along use cases: Split (gpg, pass, ssh), firewall, network, vpn, browser, dev, and vault. Then I have various app vms using those. That said, I do keep most of my templates ephemeral and I do bake secrets into some of them (like my vpn and browser). If I didn’t do the secret thing I’d probably consider consolidating templates to make updates quicker. I don’t really feel there’s a big security gain from reducing the amount of apps in a template, but if it makes you feel better you should do it.

2 Likes
15

The AppQube/Template is more appropriate than a standalone if there is a risk that the root filesystem may get modified in undesirable ways

The standalone root filesystem persists like a normal system would. An appqube’s root filesystem does not persist between instances, instead cloning the filesystem from an isolated template on each boot - the template’s filesystem remains unmolested during an appqube’s runtime

3 Likes
16

Oh yeah, that makes more sense when I think about it, my bad.

2 Likes
17

I agree. Imho it’s mostly security theater when it comes to packages
installed from the default package manager.
There’s 100+ packages installed in even the minimal templates. So
what’s the risk of having some more?
You don’t execute them, you just install them by executing their
installer scripts.

There may be some benefits for very privacy-focused users
attempting to use privacy-unfriendly software though.

My ratio is probably 20:1 or so.

2 Likes
18

When I started using QubesOS, I went with about 1:1 but found it tiresome.
I had to run my updates in every template and if I wanted to make changes I also had to modify about every other template.

Also the storage needs escalated as the, from a snapshot derived, templates changed more and more with every update applied.

I recreated my setup and now I love it.
I am now counting about 6:1

I have my base template which is good for nearly everything. It striped it down to be quite minimal but added features like Docker and a AppFirewall which I can manage on the VM-level with the qubes service definitions.

To still be able to have a small base template but very distinct AppVMs I am utilizing AppImages when possible.

Since edge cases will always exist where there is a need for a separate template, may it be due to isolation, specialization or redundancy - I think the interesting factor is:

how many AppVMs does one run from his main template:

18

1 Like
19

I think this is a fundamental misunderstanding.
Every package will install a large number of libraries - some may install
services,drivers, or kernel modules. These may be used in exploits even
if the software is never run.
Installing more software increases the attack surface.

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

3 Likes
20

It’s true, however don’t rely on this for serious security: Note on treating app qubes’ root filesystem non-persistence as a security feature

2 Likes