It’s not clear to me what threats minimizing the installed software and attack surface in this way protects against. Even if other apps in the VM have unpatched vulnerabilities, I don’t see attackers going after other user-space applications. Having a lot of templates takes up a lot of space and maintenance time, so it’s something I try to avoid. The majority of my AppVMs are based on the current Fedora template, which has all the software they all need.
I have made several templates based on the Debian minimal template. For the most part, I’ve settled on only making them when I need to add a repo or need to make changes to the template. Right now I have one for Signal, I2P, and Docker. If the program will compile or run with out needing to be installed through the package manager, such as Jdownloader, I just keep things like that in their own AppVMs. To get Docker working, I had to add user to the docker group, so I made a separate template for that. It also runs a service, so I don’t need it running in every AppVM and wasting RAM.
qubes-core-agent-networking is installed on all of those. For Signal and I2P, I also have gnome-terminal, nautilus, qubes-core-agent-nautilus, qubes-desktop-linux-common, qubes-gui-common.
@aquser there is a reason the way you are using it is the default: it’s
easier and works out of the box for the majority of users while not
requiring any extra thought in managing updates and resources.
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.
And getting there will definitely teach you about packages, dependencies
and how to resolve those. How much RAM you really need for this or that
application, when paging starts to happen etc. For me that journey has
payed in spades: I’ve never been as happy and in control with a working
environment as now.
Also: we are talking about Debian stable with apt-cacher-ng … I am
quite confident that most days all my debian templates are updated in
less time and bandwidth as it takes to get a single Fedora qube updated.
It’s a mistake to think that attacks need be against applications.
Every time you install an application, it will bring with it a number of
libraries, dependencies and recommends.
Use of those libraries from the application may be well controlled, but
an attacker may be able to chain and abuse them in unexpected ways.
That is increasing the attack surface, and using tuned templates
minimises that risk.
Space is cheap, and the maintenance burden of many templates quite small,
so it is something I am happy with.
Building on that, one thing I learned from the parent thread is to use --no-install-recommends with every package installation so you don’t end up with a crufty VM (thanks @sven).
It’s worth highlighting, especially for Linux newbies who are looking at minimals. Is there a way to enable --no-install-recommends by default, or do I have to type it out every time?
man apt.conf is helpful too.
There are many configuration options, for apt and dpkg.
Exhaustive details can be found in: /usr/share/doc/apt/examples/configure-index.gz
I strive to come as close as workable to a 1 qube per app/domain,
Do you mean by 1 template + 1 qube ? if you create a qube, what class
is it ? or you running on the template itself ?
Of course I do not run templates. There is a 1:n relationship between
most templates and qubes that are based on them. Look below and keep
asking if unclear:
The place where I use the minimal templates is generally sys-net and sys-firewall because the minimal has the smallest attack surface and the fewest number of updates required.
A) Each time you add an application to your template you increase the frequency of updates, and you take a risk of that template will become broken and unable to update and its related AppVMs unable to run. Since the minimal will have fewer total updates I have found it has been broken fewer times over the years. When other non-minimal templates become unusable I can generally still rely on my sys-net and sys-firewall to continue working so I can just download and reinstall whatever is needed to fix the problem. Its just more reliable.
B) Should an adversary ever get a toe hold on my system via an attack on sys-net then that attacker will find fewer tools available. Of course they can always download their bag of black tricks but there is no sense in my making their life any easier. The fewer tools the better but I can also add other defenses and monitoring where I feel it is required without adding that same overhead to all the other AppVMs.
