Hello all
I was reading some stuff online about qubesos and how if an appvm is compromised it can also mean the template itself it compromised. So say if i have two appvm’s based on a single template and one of those appvm’s got compromised, would it really mean that the other appvm could also be compromised? If so then I am guessing that making a template for each appvm would be better?
This one is only for that appVM because of single VM isolation that is designed by the original Qubes development team. Let’s say that the one appVM got compromised. This time is only that appVM (“untrusted”) got compromised out of all VMs in the Qubes. Therefore, only that compromised appVM is affected by that.
This more of a radical compromise to protect your Qubes. That means yes for you if you would like to do that. My recommendations for this is to upgrade your RAM and other hardware components if you wanted to be faster than the old one.
That would mean that there is a breach in Qubes OS security. The opposite is true though: if a template is compromised, all its AppVM may be compromised too.
That’s why I create some templates where I install less-trusted applications and I could end up using one template with only one AppVM. Sometimes you can install a program in the user-space of an AppVM, avoiding creating a new template.
As a suggestion, the docs are quite good on those subjects:
I don’t think so.
3 Likes
It would only help if you install different sets of packages in each template, and that you do not trust the template’s Linux distribution genuine packages.
1 Like
Right I get it. So as long as the programs installed on the template are trusted then it is safe to use multiple appvms that do different things on the same temple. And separate templates should only be made for dodgy programs such as proprietary software.
1 Like
No, it’s actually the exact opposite. The design of Qubes OS is that the compromise of an app qube does not lead to the compromise of the template on which that app qube is based or any other qube in the system. For example, you could have one template and two app qubes called “untrusted” and “vault.” Under the Qubes security model, even if “untrusted” were compromised, neither the template nor “vault” would be compromised. This is one of the main defining features of Qubes OS.
It might be better in some ways, but not for any of the reasons listed here.
2 Likes
No, I think not.
This is a subject much discussed on the lists and forum, and there is no
general consensus.
I use multiple templates, with different sets of packages in each. In my
view, it isnt a matter of “trusting the distributions genuine package”,
as @solene suggests. Many packages drop in extensive libraries and these
may be used by an attacker in an exploit. Many users seem to think that
you are safe if you have (e.g) firefox installed but do not run it -
I think this is a mistake. And so I limit the software in each template
to that which will be used in the qubes based on that template.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
4 Likes
Thanks @unman
Actually, when reading again I have no idea why I mentioned the “trusting the distributions’s packages”.
My answer should have been:
Using a separate template for each appvm would only help if you install different sets of packages in each template.
By this, I mean that if you have 2 templates using the same packages, there is no point doing so, as explained multiple times in this thread.
3 Likes
So I guess using minimal installs on each template really is the ideal then!
The only case where I could see some benefit in this would be where
one wants to separate security domains by using different base templates.
For example, the vanilla domain could be based on Fedora templates,
while another domain, where privacy might be an issue, could be based on
Arch. Some templates within those domains might have the same
packages.
Thinking about it, I have used exactly that configuration.
For a related concrete example, I think there were some interesting suggestions for making templates without network infrastructure in an earlier topic:
I believe that removing functionality from inside the template does not guarantee there are no ways for mistakes/compromise to have bad effects, but it can make it much less easy - both for it to happen, and for it to have the worst outcomes. It can be combined with other functions outside the AppVM to enhance protection from some risks.
I don’t understand why we’re dismissing this concern so easily. It’s true that minimizing the number of installed libraries limits an attacker’s ability to live off the land but this concern is not mutually exclusive with malicious upstream packages. Both deserve attention.
Either way, different package sets are still required for any real benefit.
What exactly are you suggesting beyond using minimal templates and customizing them for any particular need?
XZ did also show how hard it is to sneak a backdoor into main repos, not saying it couldn’t happen again, but it did seem like a black swan event.
In my opinion, the webp vulnerability is a better example, of an attack where minimal templates could make a difference. Having a vulnerability in a standard library, is much more likely than an actual backdoor, and it has the potential to be exploited though any application that uses that library.
Having less software installed does make it less likely someone is able to find an exploit chain.
3 Likes
- That malicious programs - either backdoored from the outset or compromised in transit - should be part of the threat model. The latter is why we use signatures on packages instead of relying purely on HTTPS (reliance on HTTPS to get the public keys in the first place is near impossible for the average person, but trust on first use is better than trust on each use).
- That opportunistic vulnerabilities and intentional backdoors are not mutually exclusive.
There is an “inverse survivorship bias” here. We only know about the ones that get caught. That line of thinking can lead to FUD if taken to far and open source is certainly more resilient to this than proprietary software, but there’s also a lot of smaller projects that get attention either as a fad or just growing quickly. Lots of room for things to slip through the cracks.
I don’t think it’s a matter of one example being better than the other. They are qualitatively different examples and both are valuable.
1 Like
Well, they are. That’s exactly the reason we have minimal templates, customize them per task and run stuff in isolated qubes. What else can we do from practical point of view? Not much beyond our current reasonable hygiene.
1 Like
I have to say, I thought the opposite. As I understand it, the xz backdoor was already out and running in the wild, albeit only on devs’ machines, and it was spotted due to its significant performance impact***. How far up the chain could it have got if it had just laid low for 6months or a year…?
[*** this is from memory]
1 Like
This is a good point that I haven’t seen people make before, although I largely avoided public discussions about this because there was a lot of hype and factionalism. It is worth noting however, that the malicious code was hidden in the release tarball in a way that wouldn’t show up in the git repository that most people look at, which was a rather clever way of avoiding the scrutiny that generally protects open source software. A move away from using release tarballs and towards building from git directly has been discussed by the GNU Guix project (and probably others, I haven’t specifically looked).
1 Like
Indeed, it struck me as a rather elegant trick, exploiting a corner case weakness of the trust chain in software distribution [***]. Undoubtedly, or maybe “hopefully”, that route is now closed, but there’s no shortage of actors out looking for others… and I fear your “inverse survivorship bias” is extremely pertinent.
I think there was some good discussion on LWN, both in articles and in the comments, including the move away from tardumps.
The whole debacle was a big encouragement to push an increasing part of my personal and professional computing to Qubes. My progress on that is not as fast as I would like, but it is coming along.
*** Edit: the exploit being necessary to evade the ‘many eyes’ effect, as you say.
The more accurate would be: for each purpose.
1 Like