How does Qubes OS work?

Hi @Hack3rcon, welcome.

The main principle at work in Qubes OS is compartimentalization, that is: keeping separate activities that use data that has different levels of value to you, or involve different levels of risk.

How you define your compartments is up to you and depends entirely on your threat model (what you want to protect, from whom, and how much inconvenience you’re willing to tolerate to achieve that goal).

For the purpose of keeping your compartments separate, Qubes OS offers tools that allow to create virtual machines (VMs) that are isolated from each other to the extent that Xen is performing its duty to do that. Additionally, as an additional measure against undesired modifications (e.g. by malware), parts of those virtual machines can be regenerated when they are rebooted: from the system files in a template-based VMs, to most of the file system in disposable VMs. Qubes OS also provides ways to move data between those VMs, so that you can for example, keep some data completely offline if that makes sense.

A good place to start learning more about Qubes OS is the official documentation. While it is quite large and can certainly look impressive, it is pretty good, and I’d recommend starting from the intro. :slightly_smiling_face:

Now to your example:

You could, yes, and you would have a few different options to do so, depending on what you’re trying to achieve.

  • If malware is your primary concern, you could create a template-based VM that you reboot after visiting sites you consider risky, so that any modification to, say, /usr/bin is reverted.
  • You could also create a disposable VM that will be entirely discarded when you shut it down, so that the next browsing session uses a fresh VM.

Note that those examples focus on security, but not necessarily privacy. (e.g. the web browsers in those VMs may still have unique fingerprints)

  • If privacy is your concern, you could use a template-based, or disposable VM based on Whonix for example.

But saying: “I will treat browsing as a separate activity” is not your only option. Taking a textbook example, you could also say: “I will treat work stuff and banking stuff as separate activities”. Each of them might involve browsing different sites, and you could create separate VMs for that purpose, so that malware installed from a website you visited for work is kept isolated from your personal banking data. Each of those compartments would be called a domain in Qubes OS parlance.

You might use multiple VMs in each domain too. For example, within your banking domain, you might want to keep your accounting spreadsheets in a VM that never has any network access, while using another VM to access your bank’s website. As you might guess, complexity can increase quickly, even though Qubes OS tooling is all about making that complexity more manageable.

Starting by thinking about your own threat model (what you want to protect, from whom, and what are the consequences if you fail) is a good way to define how much complexity is useful to achieving your goals, and how much is only making your life harder by making your activities more error-prone. :grimacing: Complexity is generally detrimental to security, so it’s all about finding the balance that works for you and that’s highly personal.


Thank you so much for your reply.
So, The Qubes OS is not a hardened OS by default. If the solution to security problems is solved by creating virtual machines, then you can use a Linux distribution and install a Type-2 virtual machine like VirtualBox on it and create your own virtual machines and do your work in them.

Others may expand on this or explain it better than I do, I’ll try nonetheless. (That’s to say, please poke holes in what I say, and please correct any mistake you spot in my reply!)

The two main differences between using Qubes OS and using virtual machines under your regular Linux distibutions are:

  • Xen runs on bare metal (Type 1), and as such has a significantly smaller attack surface than a Type 2 hypervisor. (Since you mentioned “Type 2” I suppose you’re familiar with their respective pros and cons.)

  • The operating system that you use to manage the other virtual machines (AdminVM in Qubes OS parlance, dom0 in Xen parlance) is fully isolated from the network and some hardware (e.g. USB controllers, though details do vary). That in itself reduces the attack surface in a series of scenarios that are not typically addressed in a regular Linux distro, or a typicall installation of Fedora 34 (the current dom0 OS).

Additionally Qubes OS implements tooling to manage the policies that regulate communication between VMs, a color-coding system that makes difficult for a given VM to fake the dom0 prompt that some of those policies can trigger (e.g. asking you to authorize a given VM to access a GPG function on another VM in a split-GPG scenario), mechanisms to attach logical or block devices to VMs, etc.

Depending on your needs (as usual) some of that may be beneficial.

Edit: Well and the entire VM template system! It becomes a familiar routine to the point that I forget to mention it, but that’s a piece that can bring a significant amount of convenience and would take significant effort to replicate (unless you’ve got tools I don’t know about!)

Thank you so much for your reply.
I’m sure that the Xen Hypervisor is a secure Hypervisor and has more features than type-2 Hypervisor, but does it make sense to run a virtual machine for any application? How strong should our system’s hardware specifications be?
One of Qubes OS’s biggest mistakes is that it uses Fedora. Why Fedora when there are better Linux distributions like Debian, Gentoo and even Slackware? Have you forgotten that Red Hat is the enemy of Xen Hypervisor?
In my opinion, you should use Xen Hypervisor to isolate the operating system itself and the rest of the applications run in a sandbox. The Subgraph OS is on a right track and if it adds Xen Hypervisor, then it becomes the best product.

1 Like

you don’t need a virtual machine for each application. However you could do that. Therefore hardware needs are not as big as you would assume.
One advantage is that the virtual machines itself are based on templates that can be tailored for a specific purpose and reused for different vm’s.
Another advantage are disposables that will be completely destroyed after use and closing them.
One more feature is virtual machine for tor browser
You can also control the network interaction between virtual machines that can be network proxies for each other. I.e. separating work vpn from home usage.

1 Like

VMs are already preinstalled for you, see here.

There is in practice nothing more secure than hardware virtualization, which Qubes uses by default. VM escapes are practically non-existent with such a measure.

Apart from virtualization, Qubes provides a great, unified interface, where VMs are shown as normal windows with colorful borders. Also, with easy copy-paste and file transfer, automatic backups, self-destroying VMs and much more.

No, and you don’t have to do it on Qubes (although some people do it). You use VMs as security domains, inside which everything is equally secure. For example, you do everything related to your work in one VM, everything related to your hobby in another, and everything related to your banking in the third one. Extended examples: one, two.

Debian is installed in Qubes by default, along with Fedora. Apart from them, threre are more operating systems, including Gentoo: Templates | Qubes OS.

See also my attempt to explain the feature of Qubes OS in a short pitch.

Most important is to have a lot of RAM. With 8 GB you can already have some compartmentalization, but with 16 it feels much better.

Actually, in Qubes you isolate your AdminVM from everything, including network and USB devices. You never run anything in it. Isn’t it what you mean by “isolate the operating system itself”?

I do not see how network or drivers are isolated in Subgraph OS. See also a related discussion:

Your opinion is based on what?

I am sorry if I come across as unfriendly, but the breath-taking speed from …

… to dishing out opinions and advice makes me question your motivation. Have you read any of the links posted in this thread?

Then again, three years ago you’ve asked for an updated architecture spec?

Re: Subgraph … the last alpha release was in 2017. The last commits I can see in the repositories is from 2021. I think it’s safe to say at this point that the project is abandoned.

1 Like

Updated the title from “A question about Qubes OS”


Thank you so much for your reply.
The Qubes OS is based on the Fedora. Right?
How about the templates? Should they be downloaded from the Internet? Is it possible to install a virtual machine manually?

Thank you so much for your reply.
1- You said VMs are already preinstalled. What does it mean? When you install the Qubes OS, then by default some VMs already there? Which OSes?

2- You said No, and you don’t have to do it on Qubes (although some people do it). You use VMs as security domains,… so, Is the Qubes OS a hardened OS? If yes, then why install a virtual machine?

3- How Qubes OS use both of the Debian and Fedora operating systems simultaneously?

4- Are templates complete operating systems?

Thank you so much.
Do you mean AdminVM is Qubes OS itself? If yes, then how much of the OS? For example, when you install a Linux distribution, then some applications like the Internet browser, LibreOffice, Media player and etc. are part of the distribution.

Are you sure the project is abandoned? Please check it.

Maybe this could answer some of your questions

Thank you, but I prefer that someone answer the few questions I asked.

1 Like

Yes. Here is my super-short introduction to Qubes explaining which VMs are preinstalled. They are based on Fedora by default.

Qubes OS is hardened by the fact that you run everything in VMs, which are isolated from each other by hardware virtualization.

You can have several VMs, some of which are based on Debian and some on Fedora.


Qubes is Xen, and it runs minimized Fedora in a special, privileged VM (dom0, adminVM), which is only used to manage other VMs.

On Qubes, you have all these in VMs.

© 2014 CC:BY-SH-NC

Indeed, looks abandoned.

So what do you see there that contradicts my comment?

Last alpha release was in 2017. The last commits I can see in the repositories is from 2021. Last time the posted on Twitter was in 2018.

Looks dead to me.

1 Like

It’s dead. The issues page in github has been read-only since 2021.

  • No, Qubes OS is not based on Fedora, but it uses and incorporates Fedora.
  • No, the AdminVM is not Qubes OS itself. It is one part of Qubes OS.
  • No, Qubes OS is not Xen, but it uses and incorporates Xen.

Qubes OS is its own thing. It is not Fedora or Xen, but it uses and incorporates them.

Why does this matter? Because “Ubuntu is based on Debian” is a true statement, and this type of “distro X is based on distro Y” relationship is quite common in the open-source world. So, when people say things like “Qubes is based on Fedora,” there is a real risk that people who are knowledgeable about the open-source world in general will get exactly the wrong idea about the nature of Qubes OS.


Thank you so much for your reply.
1- So, the Qubes OS itself has not been hardened. Some Linux distributions are hardened by default.

2- You said “You can have several VMs, some of which are based on Debian and some on Fedora.”, I don’t mean VM, I mean is Qubes OS itself. What kind of Linux is it based on?

3- How many VM templates are there? The Qubes OS is just 6 GB.

4- I meant do you have all these programs (Internet browser, LibreOffice and etc.) in AdminVM?