Code not running isn’t exploited. If a program is installed but not run, you can’t exploit it.
If someone broke into your qube and run the installed program with the exploit, that’s already too late anyway.
1 Like
ok, maybe not a fully thought out example, but the point i’m trying to make is to keep the attack surface minimal. like do you really want microsoft teams installed in the same qube as your bitcoin wallet, whether or not it’s running? a huge part of the qubes ideology is security through compartmentalization. also it makes it easier to just keep cloning the clean base template to build out new templates for specific use cases / software configurations. saves you from bloat dependency hell during template upgrades too.
to flip it around back to you, what reasons are there to install software directly in the base template instead of just cloning it? i can think of a few things, like i don’t care for firefox, so i could uninstall it from the base template and use my browser of choice in all the qubes based on it, but even then it still seems better to create a clone of the base template and remove firefox there.
Less bandwidth usage for update, less time for updating, a lot easier to maintain.
There is nothing wrong using multiple templates and specializing them though, but I don’t buy the argument that installing more software make the system security weaker.
2 Likes
i mean, directly from Introduction | Qubes OS
In building Qubes, our working assumption is that all software contains bugs. Not only that, but in their stampeding rush to meet deadlines, the world’s stressed-out software developers are pumping out new code at a staggering rate — far faster than the comparatively smaller population of security experts could ever hope to analyze it for vulnerabilities, much less fix everything. Rather than pretend that we can prevent these inevitable vulnerabilities from being exploited, we’ve designed Qubes under the assumption that they will be exploited. It’s only a matter of time until the next zero-day attack.
In light of this sobering reality, Qubes takes an eminently practical approach: confine, control, and contain the damage. It allows you to keep valuable data separate from risky activities, preventing cross-contamination. This means you can do everything on the same physical computer without having to worry about a single successful cyberattack taking down your entire digital life in one fell swoop.
compartmentalize everything.
My take on compartimentalization is that it separates the places where I run the software 
2 Likes
Obviously not. Not sure if this is really the best way to do it, but for a bitcoin wallet it is enough to create an appVM based on whonix-workstation and then to add Electrum under settings/applications (while removing unnecessary apps and not using it for anything else). As mentioned: Compartmentalization. Here are threads with more complex setups for wallets though.
Do you imply that minimal templates are useless? Like you, I don’t use them due to the huge management overhead (and relatively small security improvement), but I do believe that their attack surface is smaller.
At least, if a tiny malicious program can access a huge number of installed programs, it may have a higher chance of being unnoticed (since it can be smaller itself) and gain more capabilities even in an offline qube.
How would this program start itself in the first place?
They certainly have some use, but I never found those useful to me.
I’d like to remember in this thread that Qubes OS allows people to build their compartmentalized system the way they want. It’s not because I’m using a single template that it’s what everyone should do, I wanted to make a point that it’s not that bad.
It’s perfectly fine to have specialized template if one prefers doing so, or start from a minimal template and customize it heavily to your needs.
Running programs is the whole point of a computer / AppVM. My point is that a program you run may be malicious (unless you check all its code), and it can hide its actions easier when having access to a huge codebase.
I’m just asking if there is any security benefit in minimal templates, in your opinion. I would immediately agree if you say it’s small, but it seems you don’t believe it exists.
Are there any known cases of Qubes OS being compromised by a package in the main repo, where using the minimal template would have prevented it?
this seems hair-pulled
if you actually run it in an AppVM, that doesn’t mean an AppVM with the same template will be affected if you don’t run it in the other one.
the only real security risks increase when installing packages (from the official distro repo!) in a template is when you install binaries with the setuid bit set (like sudo, X, ping maybe etc…), there are many exploit that relies on setuid binaries to escalate to root. That also depends on your threat model.
If you already have no password for root or sudo, there is no use of using such exploit because it’s already super easy to escalate to root. So I don’t see much security benefit in a minimal template where you would already have to install stuff on top to make it useful.
1 Like
I don’t know the security field well enough to find specific examples, but doesn’t it seem reasonable that some malware may require common libraries installed to function? Let’s say, a keylogger would not need to reimplement xinput if it’s already installed.
I never said otherwise.
Enough damage can be done without root.
It looks to me that your threat model simply assumes that the official distro repos can never have any malicious software. This is of course a reasonable threat model to have, but what if someone else’s model is different?
1 Like
I’m dropping from this topic 
1 Like
Then they’ll make different decisions? I’m failing to see what you’re asking here… I don’t think @solene is saying one size should fit all. I was reading quite the opposite actually after the broad “do this don’t do that” statements that opened the thread without any threat modelling context.
Maybe I read that wrong 
but it seems to me like the arguments have been laid out for everyone to make informed decisions, and I don’t think that reaching an explicit agreement is necessary or particularly useful to future readers once the different perspectives have been acknowledged. Their own circumstances will require them to make all the decisions for themselves anyway. What we can bring are questions to ask in context and considerations to have in mind when making those decisions, which you’ve both done a great job at IMHO!
Again, I may be missing something, I hope not! 
Edit: Just saw your last post @solene. Not trying to pull you back in!
4 Likes
from @unman post: Why Use Minimal Templates?
It doesn’t matter if an application is started, or used.
Most packages bring in libraries and associated packages, any one of
which might provide a foothold for an attacker. That’s how the attack
surface increases, not just by bugs in running applications.
Eventually, everything has vulnerabilities.
It’s a matter of tradeoffs. After all, you can go out of your house, fall and die, but it doesn’t mean you’re going to sit at your home now, right?
1 Like
Debian 12 is ~60000 packages, the full template is ~1800, and the minimal template is ~400, and a lot of the “bloat” in the full template is applications like firefox, thunderbird, gnome, libreoffice, etc.
I don’t think the difference in attack surface is that important, and there doesn’t seem to be any reported cases of someone getting compromised by using the full template. The minimal template also relies on the user configuring the environment themselves, which can do much more harm than good.
I do think the minimal template is better than the full template, but I see better performance and lower resource requirements as the main selling points, not some vague promise of better security.
1 Like
Agreed that the right answer depends on a person’s circumstances.
The more interesting question is, whether there is a single right answer, given a particular set of circumstances. In other words, if John d’Eau explained his threat model precisely, would all of the gurus agree on what he should do? Or is there still uncertainty about the best way just because this is an evolving art? Or is a lot of this up to personal preferences, and we’d end up having a “religious” argument?
2 Likes
Like everything in life, “it depends”. Does having additional pieces of software installed in a Qube that isn’t running cause your attack surface to increase? Probably not in a way that matters. Exploit development is pretty involved these days and I can’t think of an initial attack on a normal Linux system where having X software installed, but not used matters. I guess there could be a really basic bug in the software you’re using which allows them to execute arbitrary commands locally? In that case, sure those commands not being there would cause the attack to fail. ofc, I’m not sure that the software you’re avoiding installing would be on that list.
That said, I use a number of templates and only install the software I need for that specific template into it. I do this using salt, so it’s easy to maintain and I don’t give it much thought once I set it up.
I also use the fedora minimum base template for everything. This choice is due to resource utilization and not for any security benefit. I’m not a big fan of having software running/taking up disk space when I don’t need it.
Edit: I reread the OP again. I’d say this is more a user experience thing? This can all be done relatively easily using salt, but that requires you to learn both salt and how to manage qubes with salt. Perhaps we need something between salt and hand-managed templates.
I would say this is it:
Before I started using salt, I created bash scripts. I would:
- Create the TemplateVM (by cloning another template VM),
- Copy the script onto it, then
qvm-runthe script from dom0. The new TemplateVM would then run the script, configuring itself.
The process of cloning, copying the script to the VM, then qvm-running the script could itself be automated in another script. But the point is, that setup script should give the same result every time you run it, with very little to be done manually; you can edit it when you decide to remove/add other things to that template, then rerun the process. In some cases you can probably skip step 1 (e.g., adding one more package to the script).