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

Let me share with you some historical trivia for context.
When Windows NT was first launched, it benefited for some time with this aura of safety and those who created exploits for its kernel were considered überhacker demigods.
At that time, Unix and Linux exploits were dime a dozen. Sendmail exploits week after week, wrecking havoc, it was the butt of the joke.

The only reason that Windows NT hackers enjoyed a short period of awe was because it was so novel that it required a learning curve to figure it out… and those who were really quick to crack that nut, enjoyed some reputation bump for being the pioneers, but after a while it became yet again another mundane system to crack habitually.

So, yes, of course security by obscurity will provide some level of safety but it will only work as a way to filter out the most common scripted attacks, and for tailored attacks it will act as an economical barrier of cost vs. benefit: Is it really worth to pour resources (time and money) into this obscure thing, when most of my targets are using off the shelf commercial shit? Or can we go around it finding another entry point, exploiting a system in its periphery that we already know how to attack?

If there is no other shortcut because, lets say the target’s OPSEC is tight and the guy is using only Qubes to connect to the digital world, AND if the target is so freaking valuable that it is worth it to dedicate a whole team to study this new OS to develop a chain of exploits for that particular target, then yes eventually this nut will be cracked as well.
So if we do a broad estimation, lets say a team of 10 dedicated hackers with an average salary of 100K USD for each, it would mean a minimum cost of a 1M USD a year dedicated only into focusing into one obscure OS for a specific individual.

At first these type of exploits would be highly coveted and remain in an arsenal without any disclosure.

But if as you say, if Qubes becomes more popular and enough “people of interest” start utilizing it, more eyes will be looking at this OS and several teams, both academic and foreign governments, will be looking at the same problems, and eventually some good old white hat will publish it for fame and glory at some conference, and then finally it will become trivialized when someone adds an update to metasploit making it available to any script kiddie.

At that point it won’t matter how clever or expensive it was to hack it, the most difficult hack eventually it will become trivial if there are enough collective interest to solve it.
And as with every apparent insurmountable complex problem, once you find the solution, you end up wondering if it was actually such a big deal. Hindsight is always 20/20.

And that’s why both the Xen and Qubes teams take security issues so seriously.

If a Xen or Qubes exploit were publicly published at a conference (say…without prior disclosure to the teams), i’m fairly certain you’d have a fix via Qubes updates within a week. And so, at that point, you’re protected.

Both Xen and Qubes are designed to minimize the exposed interfaces that code inside VMs can exploit to escape. In particular, Qubes’ design approach further minimizes this: e.g. designing the various Qubes protocols (gui, vchan, etc.) avoid parsing of complex/untrusted data sourced from VMs (one traditional method of VM escape exploit); e.g. Qubes developed and upstreamed Xen stub-domains which are, effectively, hardware-enforced sandboxes for QEMU. QEMU is quite complex and has had a long history of extensive security issues over the years, exposing Xen, KVM, etc. to issues if running in a privileged domain (as per usual in most environments, such as KVM). QEMU is required to support HVMs (e.g. sys-net for your wifi or a Windows OS or in general, that must see a traditional x86 PC hardware config).

Xen is already relatively lightweight. And yes, there are still XSAs and fixes for the XSAs semi-regularly. But if you look at the percent that rise to a security issue that will impact Qubes, it is low. This is because the Qubes team has designed the system to limit exposure.


There’s nothing more noble than those who protect others. Young versions of Giorgio Maone are out there but they need to be nurtured and helped.
The attacks that most seem to expect from some form of attack surface in the OS when in reality the most effective are passive in nature. The most effective hyperjack won’t be noticed and it will be the result of normal operations, not some flagrant ‘I gotcha’.
That security patches are published as regularly as they are is a demonstration of the current state of security. Both in that security improves but issues continue to exist.
Don’t trust computers. If you keep sensitive information on a networked computer or ‘smart’ device you deserve what you get.
Computer software and hardware of today feed the new ‘opiates of the masses’, convenience and entertainment. These are the real ‘attack surfaces’.
How many OSes come with a built-in security monitoring system; a system that detects and reports compromises? How many users are versed enough in forensics to protect themselves?
There is an extremely high trust level in the creators and maintainers being noble.
Oh, by the way, Have a Merry Christmas and Joyous New Year!!! (sincerely)

so much epic information here, thanks for creating this thread.

I took the freedom to change the subject line to the version of the question @adw posted “Are we safe because we’re a relatively tiny, niche OS?” It’s more to the point and also less disrespectful to everyone putting their time and energy into this project.

The answers so far – if I didn’t miss anything – didn’t account for the special nature of Qubes OS. It can’t be compared directly with other OSes as it is more of a Meta OS:

  • it let’s you use multiple virtual machines concurrently with whatever OS inside you choose
  • it provides ‘glue’ to route networking, input, output
  • it provides strictly defined minimal interfaces for data exchange between qubes
  • template based qubes add read-only system partitions

This in turn allows the user to spread their data and therefore risk among several virtual machines. The idea is not to prevent compromise but to expect it and minimize the damage. Yes, this part is based on Xen and it appears lots of people like to speculate about it’s security. But this arguing fails to account for the fact that Xen only comes into play when your qube is already compromised. Regardless of which OS you run inside that qube (the one you are apparently comparing Qubes OS to). On any “non-Qubes OS machine” now would already be game over. The attacker won and has all of your data. End of story.

Does Windows/Linux become more secure by running it in Qubes OS? No it doesn’t. What Qubes OS gives you is the ability to firewall that qube and you don’t have to “put all of your eggs in one basket”. So if that one qube goes, only the data that was in it get’s exposed.

I am less than mildly surprised most of you genuinely seem to overlook this basic architecture and frankly this should be your main reason for using Qubes OS. If you didn’t understand this part, then you are using Qubes OS as “magic pixy dust” and I am not surprised anymore at the form of the question.

Any other OS that has had more scrutiny can be run inside of your qube. You can go crazy there. The reason many of us don’t bother to go crazy with the hardening is the realization that once you have everything that is valuable compartmentalized into offline qubes eventual compromises of the online qubes aren’t that big a deal anymore … especially if those are disposable.

Yeah, but … XEN!!!

Ok, but now we hopefully agree that what we are really comparing is the attack surface and maturity of XEN in the form it is used in Qubes OS with the entirety of e.g. Windows or Linux. And from an attacker’s point of view it becomes even more clear: once they have a Windows/Linux based exploit they own everything that’s on a “normal” machine. On a Qubes OS machine they now own that qube, but then have to also have a XEN exploit that actually works in Qubes OS to get the rest of the data.

So it’s SuperHardOS™ against Qubes/XEN + SuperHardOS™. Qubes OS really is more of an additional layer of protection and an architectural trick to help you limit the damage of eventual compromise once your SuperHardOS™ was defeated.


We all understand that. The question is, Xen is really THAT safe, or just because nobody did put “real” effort into hacking it yet (say, put a $1M price tag for a working exploit chain)

duplicate post

Well, looking at the number of results for “xen” vs. “vmware” searching the metasploit framework here, i know what i trust more, even before the Qubes team added their thoughtful designs:

Look, this conversation is just going to continue to be circular unless you approach this in a professional manner. What is the problem you are trying to solve? What is your threat model?

Otherwise, there’s always this: Mickens on Security - Schneier on Security




We all understand that.

Then why pose the question this particular way? What’s your aim?

The question is, Xen is really THAT safe, or just because nobody did put “real” effort into hacking it yet (say, put a $1M price tag for a working exploit chain)

It is exceedingly likely that there still are exploitable bugs in Xen. New ones might be added at a later time. Sooner or later someone will find and exploit them.

Now what?

Use Windows/MacOS/Linux/BSD without Qubes OS. That improves security how?

The entire point of Qubes OS is to reduce the amount of people and code you have to trust. This is it: the Qubes OS team, the Qubes OS code and XEN code (plus the whole root of trust thing when booting). That’s the bargain, form the start. Is it perfect? Nobody ever claimed it is.

But it’s a whole lot better than all the alternatives I am aware of.


The question was about “how important for us is to keep low profile” :)) not that we do it voluntarily by now :))

2 posts were split to a new topic: What OS do congressional staffers / the intelligence community use?

“better” is hardly an absolute. As much as I like the ideas behind seL4, it does not look clear how much it is usable as an hypervisor today on x86 hardware. Supported Platforms | seL4 docs says it supports VT-x and VT-d, but their FAQ says otherwise:


No mention of AMD-V and AMD-Vi in this. Their reference x86 VMM lists as prerequisites:

Isn’t it kind of a moot point? It wouldn’t be possible for us to intentionally keep a low profile. We’re a transparent open-source project. All of code is in public GitHub repos. The very discussion we’re having now is on a public forum.

Well, you may keep a low profile in open sight. It is all not just about how you do it, but more about who depends on your project :slight_smile:

Right, but we can’t prevent anyone from using Qubes or prevent it from becoming more popular (except indirectly, I suppose, via various forms of self-sabotage).

1 Like

How do you help improving a project if you just keep it hidden, anyway ?

Well, it might be not that clear, my question was: are we prepared for that to happen? Will our security model stand or do we need a better strategy and different vision?

well the security model wasnt to have an operating system that is only used by a few thausand people. so even if it got in the millions of users, the security model would still be compartmentalisation.

1 Like

English is far from my first language, but the more I read the topic the more I think its title isn’t well chosen.
I am Qubes OS user. Am I OS (relatively tiny nice)? No. So, I’m asking myself, should the title be - Are we safe because we use relatively tiny, niche OS?
So, who is OS? Marmarek and the rest of the team, obviously. So, the title again doesn’t sound well - “We” in the title doesn’t stand for the team, since the OP isn’t part of it, as far as I follow.
So, Are they safe because they’re a relatively tiny, niche OS? sounds more proper. But, why any of us users would care if they would be safe because they are relatively tiny, niche OS? I mean, they know it better then us, so they’re at least safer then us users.
Which leads me to the conclusion that Do they think we are safe, because we use them (relatively tiny, niche OS)? is again more suitable title.
Yet, reading it like this, it could mean that we want to use them- meaning to take advantage on them, and that could make them angry so they could abandon the project, and then no one is nor can be safe.
At the end, as so many times so far in my life, I learned that sometimes some questions are better if not asked…

Happy New Year!

…, so I stopped asking myself about the proper topic title.

It’s understandable in English, but may not directly translate. The “We” in the title is the Qubes community, and the way the title is phrased makes us synonymous with the OS we use. It makes sense, but would be clearer, especially for those for whom English is not their first language, to say:

Are QubesOS users safe because it is a relatively tiny, niche OS?