Sandboxing is a security mechanism supported by OPSEC experts to defend against cyber-attacks, as well as a method to prevent loss of data. In spite of its widespread use, is sandboxing enough to deter data intruders from pilfering massive data, or is it another hyperbole paraded as truth?
The question remains: if encryption or cryptographic methods have security leaks, then how exactly does domain sandboxing work? In theory, wouldn’t it depend on cryptographic methods to prevent domain A from accessing the data of domain B?
Sandboxing can be defined as a method of creating a partition between domains, or a method of separating domains from one another. Logically, it’s similar to a military training facility: you can train with potentially lethal weapons and tactics in a controlled environment, while minimizing the risk of actual damage and injury.
Technically, although Qubes is not the only operating system to support virtualization, it is the first operating system with domains allocated to special functions. Polish computer security researchers Joanna Rutkowska and Rafal Wojtczuk began working on Qubes in 2010. The method of sandboxing employed by Qubes differs from the day-to-day virtualization implemented by most software vendors.
Qubes’ virtualization is based on Xen, an open source hypervisor model. It is often touted as the best by users with extensive experience.
A hypervisor is simply a virtual machine (VM) monitor which enables operating systems to host more than one VM on a host machine. This is also known as virtualization. Qubes OS is designed to provide security by isolation.
Qubes OS features the following function virtual domains for users:
Dom0 is the most privileged domain out of all the domains, as well as the most sensitive. It has direct access to the host hardware. Being that it is sensitive, it is isolated from other domains, in particular the NetworkVM.
Dom0 hosts the GUI domain and controls the graphics device, as well as input devices, such as the keyboard and mouse. The GUI domain runs the X server, which displays such things as the user desktop, and the window manager, which allows the user to start and stop the applications and manipulate their windows.
AppVMs are VMs used for hosting user applications, such as a web browser, an e-mail client, or a text editor. For security purposes, these apps can be grouped into different domains (e.g. “personal,” “work,” “shopping,” “bank,” etc.). The security domains are implemented separately. Think of VMs as being isolated from each other as if they were separate physical computers.
The network mechanism is the one most exposed to security attacks. For this reason, it is isolated in a separate, unprivileged VM, called the Network Domain. An additional proxy VM is used for advanced networking configuration.
Disk space is saved by virtue of assorted VMs sharing the same root file system in a read-only mode. Separate disk storage is only allocated for the user’s directory and per-VM settings. This allows software installation and updates to be centralized. Of course, some software can only be installed 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 NetworkVM is known to be the most vulnerable to attack vectors. Also, within the AppVM, a user is more likely to be attacked by viruses, Trojans, keyloggers, and other types of malware. Thus, it is the chief reason why the developers of Qubes decided to increase the proximity between the Dom0 and the NetworkVM.
It seems that the developers of Qubes believe that the best way to protect the Dom0 from keyloggers or Trojans is separate it from the AppVM. In theory, we can assert that it is at least safe to operate on Qubes, but this isn’t always the case.
Is it Safe?
According to the technical documentation concerning Qubes’ structure, domains are separated from each other via encryption. Like the Dom0, the storage domain is protected from other domains via encryption to prevent malware in other domains (such as the NetworkVM) from spreading.
If the storage domain were to be part of, or closely connected to, other domains, then the concept 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 take advantage of Qubes’ intention to protect domains by isolation, let’s ponder over the following questions:
- Why should Qubes allow users to set domain policies on their own, instead of implementing a wizard tool to automate settings? Is manual configuration better than wizard configuration?
- Is the encryption between the storage domain and 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 NetworkVM to the StorageVM?
Problems with Qubes’ Security Methods
Personally, I don’t have any problem with Qubes. That being said, if Rutkowska confirmed that it is impossible to avoid bugs, then how can she assure users that Qubes is capable of sandboxing Trojans and malicious software from domains on Qubes?
In spite of Rutkowska’s opinion that the sandboxing method is secure, there are two other areas and techniques which could break the isolation method being implemented by Qubes developers.
It appears that Qubes depends on a backup system to prevent huge losses of data. By default, the backup system relies on a weak key derivation function (KDF). For that reason, it is recommended that users select a high-entropy passphrase for use with Qubes backups.
In all honesty, however, I have yet to find out if the backup system is a better method of avoiding heavy losses of data. According to Qubes’ security team, a user can send backup documents to the AppVM. My question here is: does the user know whether or not the AppVM is devoid of worms or viruses?
First Area of Vulnerability: According to Rutkowska, users are allowed to configure domain settings on their own. The problem with this is that not all users are familiar with technical settings. As HAL 9000 said in 2001: A Space Odyssey, “It can only be attributable to human error.” It’s fair to assume that hackers would be aware of manual security policies, take advantage of haphazard configuration, and eventually inject viruses and Trojans into the user’s domain.
In other words, it stands to reason that hackers would count on human error to leave vulnerabilities in a user’s domain. In spite of the isolation methods implemented by Qubes, users’ unseen mistakes may act as vectors, or security holes, which could compromise Qubes’ in-depth security.
Second Area of Vulnerability: Qubes does not allow users to ‘send’ or ‘transport’ files and folders; instead, it gives them the ability to copy and paste these resources. For example, let’s assume that a user downloads a file or program from a phished website (disguised as an https site). Later, the file or program downloaded from the phished website could be copied from the AppVM to the StorageVM.
The StorageVM is encrypted from the NetworkVM to prevent replication of malware. Is the encryption method employed by Qubes secure enough to prevent malicious software in the AppVM from attaching itself to the StorageVM?
In conclusion, we may one day hear of a new zero-day attack on Qubes OS. Qubes’ complexity is not invulnerable to compromise, but it is still more reliable than most operating systems.
So, while it may not be “invincible,” so to speak, it is still a viable option. Just be aware of its limitations.