Are we safe because we’re a relatively tiny, niche OS?

Imagine a big tech company investing huge into Qubes development – and contributes everything back to upstream.

They make it manageable for an average enterprise admin (yes, this includes the whole Win10 guest management stack) and totally usable for an average enterprise user.

So, every security-savvy company starts using Qubes as a default workstation.

At the end of the day, all TAO / CIA / whatever TLA have a dedicated Qubes task force. Hacking Qubes becomes a holy grail of IC.

Would the whole game change be beneficial for us tinfoil hat nerds?


not quite understand your post

both yes and no
yes because more investment in security will goes to qubes
no because more attacker will attack qubes and weaken it

but there still more good than bad

1 Like

I would say that security as a whole would become considerably more hardened in the face of greater threats - resulting in defense measures that dwarf the security standards of today.

However, that doesn’t mean that the average Qubes user would realize the same relative defense advantages over others as the pool of skilled attackers would increase.

The average Qubes user would not be able to rely on “out of the box” solutions or simply being one of the few “in the know” to enjoy the relative defense advantages of today. While the playing field would be hardened, it would be more even - requiring even more knowledge and skill for the average user to enjoy the same relative advantages against common threats.

That’s of course assuming that the tendency for “red teams” to be one step ahead of “blue teams” remains the case. I suppose it’s possible that innovations in computer science and technology could lead to a global tendency towards “blue team” dominance, but I suspect that underlying political and economic incentives will likely prevent that from happening. For some reason, the world seems to innovate, create and grow more when dealing with significant threats both real and perceived.

As a thinfoil hat nerd, my comment couldn’t be other than: It would be like in sports. Big teams don’t buy great players to play for them, but not to play for the competition. And there, most of them sit on the bench, waiting for… Godot?

Qubes forks would be inevitable.

I think Linux isn’t as secure as some open source evangelists would like people to believe, so the strength of Qubes lies in its compartmentalization, which is based on entirely on the assupmtion that Xen is hard to penetrate.

With virtualization already a key part of how cloud services operate, it isn’t a stretch to think that it is already in the crosshairs of malware developers–just not at the priority level that mass adoption of Qubes would lead to.

Xen is a relatively bloated hypervisor compared to other solutions, and my impression is that bloat equals complexity equals vulnerability (cf. Log4Shell). Once the demand is there, Xen is in trouble. Chain whatever findings to Linux vulnerabilities, and Qubes is in trouble.

One solution might be to move to a better hypervisor (SeL4?).

Also interesting is the implications this chain of thought has for Qubes open hacking competitions with rewards–what should ITL be responsible for if novel Xen and/or Linux attacks, and not Qubes-code-specific attack were used? Should ITL still be responsible? If not, why bother with the competition? Any competition with payouts should be in tandem with the developers of these software platforms.


This is “General Discussion” material. Moved it there.

SeL4 :+1:

AFAIK it’s not exactly true. The strength of Qubes’ compartmentalization lies mostly in the hardware virtualization. Especially if you minimize the interactions between important VMs, which is what you should do if security matters for you.

And isn’t this hardware virtualization controlled by Xen? I’m not technical, but isn’t hypervisor breakout or VM escape a thing?

Am I mistaken in believing that a sufficiently serious security breach of Xen, which underwrites everything in Qubes including dom0, means the attackers can potentially have access to everything built on the hypervisor either directly or via dom0? I’d like to be educated on the matter.

Also, don’t forget the unknown unknowns, like Spectre/Meltdown/Rowhammer, or even Log4Shell.

Edit: also found this article that’s directly relevant as it quotes Qubes devs:

Now I get that you mean PVH mode (which is the solution for the above, and has been implemented by default in all except VMs that use PCI devices) but can you say for certain issues of similar seriousness will never pop up in the future?

Yes. But how hard such escape is, depends on the virtualization technology. Before 4.0, Qubes used para-virtualized mode, resulting in escapes.

Perhaps a more knowledgeable person could correct me, but I think not. See also: Blue Pill (software) - Wikipedia and A quote from the latter:

Rutkowska and her team have presented numerous attacks against virtualization systems and Intel security technologies, including a famous series of exploits against Intel Trusted Execution Technology. Their attack against Intel VT-d, allowing a full VM escape, is still the only one that has been demonstrated to this date, and they famously demonstrated that it is possible to break into Intel vPro BIOS and Active Management Technology. Rutkowska is also renowned in the security community for writing Blue Pill, the first hardware virtualization-based rootkit

As I mentioned before, preventing hypervisor escape is just one tiny part of the overall security (and we need more security audits for sure). We need systemic analysis of the attack surface, and what might be just as important, we want to be very dangerous targets thanks to advanced detection. Typical “western” adversary won’t risk a 0day to burn, and what is more important, a typical operator is not in the authority position to endanger the offensive capability if such a risk emerges (unfortunately, cannot say the same about “other types”),

i don’t think others have mentioned this yet, but TLAs are not in everyone’s threat model. with a wide-scale adoption of qubes, the security of the project would heavily increase due to more funding and scrutiny, and the bar for compromising a system (or deanonymizing users) would go from finding a browser exploit to breaking out of Xen (which, we would assume, would be a lot harder to do). it will also make TLAs actually have to devote time to breaking qubes, and i doubt they would burn Xen zero days to compromise the newly larger community of users (because target selection also becomes more difficult if we assume more and more people use qubes-whonix) – and more users to attack means IC is less likely to attack you, which gets zero days fixed after they’re used on more important targets (not considering that zero days could be stockpiled, but we also assume that finding them is difficult)

1 Like

But as of now, even if you are a high-value target for TLAs, Qubes is extremely unlikely to be your point of compromise. This may change.

I think we suck because we are safe.

Adversity is the mother of invention.

1 Like

As a statement, I take issue with that. As compared to… ?


And at the end of the day people fall on associating credit card with the anonymous email (kickass torrents owner), or posting an real email address under anonymous nick (Silk Road owner).
To hide is to lie, and it is so hard to lie all the time…


Are we safe because we’re a relatively tiny, niche OS?

To a certain extent, yes. All real-world security ultimately depends on how many resources your adversary is willing to expend. In practice, there’s no “perfect level of security” for a usable computing system that’s guaranteed to remain impervious even in the face of the rest of the physical universe being directed toward breaching it. (Sufficiently strong encryption can offer such guarantees for data at rest, but then you can never decrypt it. Once you involve an act of decryption, you have to assume a usable system with many more moving parts and potential points of attack, including the physical environment in which the computing system is used and the fallible sapients operating it.)

In this sense, it doesn’t matter whether it’s the Qubes OS we have today or a theoretical future version that’s a thousand times stronger. The general principle remains the same: Security is always relative to the strength of your adversary.

In practice, today, it’s likely that Qubes being relatively small and niche results in attackers spending relatively fewer resources on breaking it, but this depends on unknown factors. We don’t know how many high-value targets are using Qubes. (There is reason to expect that high-value targets might disproportionately self-select into using Qubes over non-security-focused OSes.) We do know that it’s nowhere near as popular as, say, Windows and macOS. An attacker motivated purely by profit stands to gain vastly more by targeting Windows users, so it’s unlikely that such an attacker would spend more resources for less potential gain by targeting Qubes. On the other hand, a well-funded attacker specifically targeting certain individuals might be motivated to devise methods to compromise whatever systems the target happens to rely upon. This might turn out to be Qubes, but Qubes might not be the easiest entry point against that target. That might instead turn out to be the target’s mobile device, home security system, place of business, friends, or something else.


Let’s say this:

  • yes we are safe at home to avoid attacks
  • no for you if you are not using Qubes OS due too many hacking attempts
  • maybe we are sucks for using something that is not protecting our data from the spams

I agree this message for what our government has done for the bad projects