User:Brunogabuzomeu/sandbox

Qubes OS
	Applications running in different virtual machines
Developer	Invisible Things Lab
OS family	Xen, Unix-like
Working state	Current
Source model	Free and open source software (except for Windows Support Tools)
Initial release	2012/09/03
Latest release	1.0 / September 3, 2012
Available in	Multilingual
Update method	Yum (PackageKit)
Package manager	RPM Package Manager
Platforms	x86-64
Kernel type	Hybrid (Xen and Linux)
Userland	Fedora
Default; user interface	KDE
License	GPL v2
Official website	qubes-os.org

Qubes OS is a security-oriented, Fedora-based desktop Linux distribution whose main concept is "security by isolation" by using domains implemented as lightweight Xen virtual machines.

It attempts to combine two contradictory goals: how to make the isolation between domains as strong as possible, mainly due to clever architecture that minimises the amount of trusted code, and how to make this isolation as seamless and easy as possible.^[3]

Security Goals edit

Qubes implements Security by Isolation approach by providing a user with ability to easily create many security domains. Those domains are implemented as lightweight Virtual Machines (VMs) running under the Xen hypervisor. Qubes' main objective is to provide strong isolation between these domains, so that even if the attacker compromise one of the domains, the others are still safe.

Qubes, however, does not attempt to provide any security isolation for applications that run within the same domain. E.g. a buggy web browser running in one of the Qubes domains could still be compromised just as easily as on regular Linux OS. The difference that Qubes makes, is that now the attacker doesn't have access to all the other software running in the other domains.

Qubes also provides a number of mechanisms that make it easy and convenient for the user to run multiply domains, such as seamless GUI integration onto one common desktop, secure clipboard copy and paste between domains, secure file transfer between domains, disposable VMs, etc.

One of the main goals of Qubes OS is to provide seamless integration of the various applications hosted in different VMs onto a common user desktop, so that it is easy for the not-technical user to work with all the applications, regardless of what VMs they are hosted in. Specifically, we assume that all the user applications, except for X Window Manager, and management applications, would be hosted in Application VMs.

Qubes does not pretend to be a multi-user system.

System architecture overview edit

Xen hypervisor and administrative domain (Dom0) edit

The hypervisor provides isolation between different virtual machines. The administrative domain, also referred to as Dom0, is almost as privileged as the hypervisor. It has direct access to hardware.

Dom0 also hosts the GUI domain. It has direct access to 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 that allows to start and stop the applications and manipulate their windows. The most common application that runs in the GUI domain is the Application Viewer, a little stub application that is used to launch and then display the content of the actual application hosted in some AppVM. AppViewer provides an illusion for the user that the application executes natively on the desktop, while in fact it is hosted (and isolated) in an AppVM.

The GUI domain is security critical, because if one controls this domain, one can mimic any action that the legitimate user could also perform, including starting and operating all the applications in all AppVMs. Because the GUI domain is security-sensitive, there is no world-facing code running in this domain. E.g. there is no networking code in the GUI domain. Also it has a very simple and slim interface used to communicate with other domains (in order to display windows of application running in AppVMs), to minimize the possibility of an attack originating from one of the AppVMs.

Even though Dom0 runs a regular Linux OS, the interface to Dom0 is very minimal (just GUI and Xen Store), and hence the potential attack surface (and the amount of code to audit) if also very minimal.

The storage domain edit

Qubes tries to optimize disk usage by virtual machines. The sophisticated file sharing mechanisms (e.g. copy-on-write filesystem) require complex code on the backend side. Having such a code in the administrative domain (Dom0) would increase the attack surface on the system. To mitigate this risk, the filesystem sharing code, the backends, together with disk drivers and stack, are moved to dedicated unprivileged VM, the so called storage domain.

The storage domain has direct access to the disk controller, granted via Intel VT-d technology, similarly as the network domain has access to the networking hardware. Additionally, the storage domain has access to USB and CD/DVD controllers to allow it to handle all the removable storage devices, such as USB flash drivers or CD/DVD discs. This also allows to mitigate attacks originating from removable devices, e.g. specially formatted USB drive that tries to exploit a potential bug in the USB driver.

Cryptography is used to protect the filesystems, so that the storage domain cannot read confidential data owned by other domains, nor it could modify (in a meaningful way) the shared root filesystems. Additionally we make use of Intel Trusted Execution Technology (TXT) in order to prevent modification of the system boot code. This means that the storage domain, if compromised by the attacker, can, in the worst case, make the system unbootable but cannot compromise the system, e.g. by installing backdoors or rootkits and steal the user data.

The network domain edit

In the Qubes architecture we try to limit potential attack vectors on the system as much as possible. Thatʼs why the whole networking code, including drivers and protocol stacks, has been moved out to an unprivileged VM, called the Network Domain.

The network domain has direct access to the networking hardware, i.e. the WiFi and ethernet cards. The access is granted via Intel VT-d technology, that allows for safe device assignment to unprivileged code.

When a potential bug in the networking code, e.g. in the WiFi driver, is exploited by an attacker, all that the attacker can gain is the control over the network domain, but not on any other VM.

Advanced networking is possible through the creation of multiple network VMs (that isolate all the world-facing networking stacks) and proxy VMs that could be used for advanced VPN and tunnelling over untrusted connections.

The Applications Virtual Machines (AppVM) edit

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 as separate, lightweight Virtual Machines (VMs), thus being isolated from each other as if they were executing on different machines.

Each security domain is labelled by a color, and each window is marked by the color of the domain it belongs to. Thanks to that approach it is always clearly visible to which domain a given window belongs.

Some documents or application can be run in disposable VMs through an action available in the file manager. After viewing the document or application, then whole Disposable VM get destroyed.

Qubes makes special effort to save on the disk space used by the virtual machines. E.g. all the AppVMs based on the same system distribution should share the same read-only file system, and only use separate disk storage for userʼs directory and per-VM settings. This allows to save tens of gigabytes of disk space, which otherwise would be wasted to replicate full OS image for each VM. It also allows to centralize software installation and updates for all AppVMs based on the same template. Software can also be installed only on a specific AppVM.

Additionally, the VM-specific private data are kept on a per-VM image file in the storage domain (this device is read-write, of course).