Does Qube OS Has A Leak Hole ?

Another ideal option supported by opsec  experts  against cyber- attacks, and to prevent loss of data is Sandboxing. But is sandboxing enough to deter data intruders from pilfering massive data or is it another hyperbole paraded as a truth?

The truth above all else is : if encryption or cryptographic methods have leak holes, what’s the essence of  domain sandboxing ?  Don’t you think sandboxing depends on cryptographic  method to prevent domain A from accessing the data of domain B?

Sandboxing can be defined as a partition of domains or separation of domains from each other. Logically, it is similar to the block of cells at Guantanamo Bay Detention Camp.

Technically, although Qubes  is not the only operating system to support virtualization, it is  the only or first operating system with domains allocated with special functions.  Qubes sandboxing is widely different from  day –to –day virtualization implemented by software vendors.

Qubes’ virtualization is based on Xen, an open source hypervisor model. It is touted as the most preferred among others.

Hypervisor is simply a virtual machine monitor which enables operating system to host more than one virtual machines on a host machine. It is known as Virtualization. Qubes OS is designed to provide security by isolation .

Qube OS has the following functional virtual domains for a user :


It is the most privileged domain among other domains and also the most sensitive. It has direct access to the host hardware . Because it is sensitive, it is isolated from other domains especially the Network Vm . Dom0 hosts the GUI domain and controls the graphics device, as well as input devices, such as keyboard and mouse. The GUI domain runs the X server, which displays the user desktop, and the window manager, which allows the user to start and stop the applications and manipulate their windows.

App Vm  –

AppVMs are the virtual machines used for hosting user applications, such as a web browser, an e-mail client or a text editor. For security purpose, these applications can be grouped in different domains, such as “personal”, “work”, “shopping”, “bank”, etc. The security domains are implemented separately. Virtual Machines (VMs), thus being isolated from each other as if they were executing on different machines.

Network Vm

The network mechanism is the most exposed to security attacks. This is why it is isolated in a separate, unprivileged virtual machine, called the Network Domain. An additional proxy virtual machine is used for advanced networking configuration .

Storage Domain

Disk space is saved by virtue of various virtual machines (VM) sharing the same root file system in a read-only mode. Separate disk storage is only used for userʼs directory and per-VM settings. This allows software installation and updates to be centralized. Of course, some software can be installed only on a specific VM. Encryption is used to protect the file systems, so that the storage domain cannot read confidential data owned by other domains.

Among the domains or Vm’s on Qubes OS , the Network Vm is touted as the most viable to attack vectors  . Also within the App Vm, a user is likely to be attacked by viruses, trojans, keyloggers, and other malicious softwares .  Thus, it is the chief reason why the developers of Qubes OS decided to increase the proximity between  the Dom0 and the Network Vm.

So it seems the developers of Qubes OS have in mind that the best possible option to protect the Dom0 from keyloggers or trojans is to separate it from the App Vm. Therefore, we can assert (that) it is at least safe to operate on Qubes but not entirely .

According to technical documentation concerning Qubes structure, domains are separated from each other  via encryption . Like the Dom0, the storage domain is literally protected from other domains via encryption to prevent viruses in other domains [ such as Network Vm ] from penetrating into each other.

If the storage domain were to be part or closely connected to other domains, then the essence of  security by isolation does not practically implement its intention to secure domains from each other .

However, those in the opsec industry should [by now] be aware of  how connected devices [ or even separated devices like a wireless keyboard and computer] are susceptible to malicious agents.

Even before I move on to how hackers can manage to detonate Qube intention to protect domains by isolation, lets ponder over the following questions :

Why should Joanna allow users to set domain policies on their own instead of implementing a wizard tool to automate settings ? Or perhaps manual configuration is better than wizard configuration ?

Is the encryption between the storage domain and the others resilient enough without hidden bugs ?

Is the Dom0 completely protected from Rootkits ?

How does the encryption mode between domains prevent viruses from moving the Network Vm to Storage Vm ?

The  Problem With Qube Mode of Security 

Honestly, I don’t have any problem with Qube OS.  But if Joanna confirmed it is impossible to avoid bugs, then why should she assure users that Qube OS is capable of sandboxing trojans and malicious software from domains on Qube OS.

In spite of Joanna’s opinion, there are other  two  areas  and techniques which could detonate isolation method being implemented  by Qube OS developers .

Seemingly, Qubes OS depends on a backup system to prevent huge mass of data.  In default, the backup system relies on weak key derivation scheme . So it is recommended that users select a high-entropy passphrase for use with Qubes backups  .

But in all honesty, I have yet to find out if the backup system is a better option of avoiding heavy loss of data. Because according to Qubes security team,  a user  can send  backup documents to the App Vm. My concern here is : Does the user knows whether the App Vm is void of worms or viruses ?

First Area Of Vulnerability   :  According to Joanna,  users are allowed to configure domain settings on their own.  Of course not  all users are familiar with technical settings. In addition, humans are prone to mistakes ; so we should expect hackers to be aware of manual security policies , take advantage of  haphazard configuration and eventually inject viruses and trojans into users domain .

Therefore hackers may count on human mistakes to compromise users domain. So in spite of the isolation method implemented by Qubes, users’ unseen mistakes may act as attack vectors or ‘leak holes’ which could compromise Qubes in-depth security .

Second Area Of Vulnerability :  Qubes allows users not to ‘send’ or ‘transport’ but to copy and paste files and folders . Let’s assume users download a file or a program from a ‘phished’ website ( designated as an https website ) unknowingly . Later, the file or program downloaded from the phished website is copied from the App Vm to the Storage Vm.

The storage Vm is encrypted from the Network Vm to prevent replication of malwares ( i.e virus ) .  Can the encryption method employed to prevent malicious software in the programs or folders on the App Vm from attaching itself to the Storage Vm ?

Nevertheless, we should not be surprised to hear of a new zero-day attack on Qubes OS . The complexity of Qubes OS is not invulnerable to compromise. But we can count on Qubes OS as the most reliable than other OSes.

Share and Enjoy

  • FacebookFacebook
  • TwitterTwitter
  • DeliciousDelicious
  • LinkedInLinkedIn
  • StumbleUponStumbleUpon
  • Add to favoritesAdd to favorites
  • EmailEmail