There are not many articles on Habré devoted to the Qubes operating system, and those that I have seen do not describe the experience of application. Under the cut, I hope to fix this using the example of using Qubes as a means of protection (against) the Windows environment and, along the way, estimate the number of Russian-speaking users of the system.
Why Qubes?
The history of the end of technical support for Windows 7 and the increasing anxiety of users led to the need to organize the work of this OS, taking into account the following requirements:
- ensure the use of a full-fledged activated Windows 7 with the ability to install updates and various applications by the user (including via the Internet);
- implement complete or selective exclusion of network interactions by condition (modes of offline operation and traffic filtering);
- provide the ability to selectively connect removable media and devices.
Such a set of restrictions presupposes a clearly trained user, since self-administration is allowed, and the restrictions are not related to blocking his potential actions, but to the exclusion of possible errors or destructive software impact. Those. There is no internal violator in the model.
In search of a solution, we quickly abandoned the idea of implementing restrictions with built-in or additional Windows tools, since it is quite difficult to effectively restrict a user with administrator rights, leaving him the ability to install applications.
The next solution was isolation through virtualization. Well-known desktop virtualization tools (for example, such as virtualbox) are poorly adapted to solving security problems, and the listed restrictions will have to be made by the user by constantly switching or configuring the properties of the guest virtual machine (hereinafter referred to as VM), which increases the risk of errors.
At the same time, we had experience using Qubes as a user's desktop, but there were doubts about the stability of working with a Windows guest. It was decided to check the current version of Qubes, since the set restrictions fit very well into the paradigm of this system, especially the implementation of virtual machine templates and visual integration. Next, I will try to briefly talk about the ideas and tools of Qubes, using the example of solving the problem at hand.
Types of Xen virtualization
Qubes is based on the Xen hypervisor, which minimizes the resource management functions of the processor, memory, and virtual machines. All other work with devices is concentrated in dom0 based on the Linux kernel (Qubes uses the Fedora distribution for dom0).
Xen supports several types of virtualization (I will give examples for Intel architecture, although Xen supports others):
- paravirtualization (PV) - virtualization mode without the use of hardware support, reminiscent of container virtualization, can be used for systems with an adapted kernel (dom0 operates in this mode);
- full virtualization (HVM) - in this mode, hardware support is used for processor resources, and all other hardware is emulated using QEMU. This is the most versatile way to launch various operating systems;
- hardware paravirtualization (PVH - ParaVirtualized Hardware) is a virtualization mode using hardware support when the guest kernel uses drivers adapted to the capabilities of the hypervisor (for example, shared memory) to work with the hardware, removing the need for QEMU emulation and increasing I / O performance. The Linux kernel since 4.11 can run in this mode.
Starting with Qubes 4.0, for security reasons, the paravirtualization mode is not used (including due to known vulnerabilities in the Intel architecture, which are partially removed using full-fledged virtualization), the PVH mode is used by default.
When using emulation (HVM mode), QEMU is launched in an isolated VM called stubdomain, thereby reducing the risks of exploiting potential errors in the implementation (the QEMU project contains a lot of code, including for compatibility).
This mode in our case should be used for Windows.
Service virtual machines
In the Qubes security architecture, one of the key features of the hypervisor is the transfer of PCI devices to the guest environment. Hardware exclusion allows you to isolate the host part of the system from external attacks. Xen supports this for PV and HVM modes, in the second case it requires support for IOMMU (Intel VT-d) - hardware memory management for virtualized devices.
Several system virtual machines are created in this way:
- sys-net, to which network devices are transferred and which is used as a bridge for other VMs, for example, those that implement the functions of a firewall or a VPN client;
- sys-usb, which is passed to USB and other peripheral controllers;
- sys-firewall, which does not use devices, but acts as a firewall for connected VMs.
To work with USB devices, proxy services are used, which provide, among other things:
- for the HID (human interface device) device class, sending commands to dom0;
- for removable media, redirecting device volumes to other VMs (except for dom0);
- direct redirection of the USB device (uses USBIP and integration tools).
In this configuration, a successful attack through the network stack or connected devices can only compromise the running service VM, not the entire system. And after restarting the service VM, it will be loaded in its original state.
VM integration tools
There are several ways to interact with the desktop of a virtual machine - installing applications in the guest system or emulating video with virtualization tools. Guest applications can be various universal remote access tools (RDP, VNC, Spice, etc.) or adapted to a specific hypervisor (such instrumentation is usually called guest utilities). A mixed version can also be used, when the hypervisor emulates I / O for the guest system, and outside it provides the ability to use a protocol that combines I / O, for example, like Spice. At the same time, remote access tools usually optimize the image, since they involve working through a network, which does not affect the picture quality for the better.
Qubes provides its own tools for VM integration. First of all, this is a graphic subsystem - windows from different VMs are displayed on a single desktop with their own color framing. In general, integration tools are based on the capabilities of the hypervisor - shared memory (Xen grant table), notification tools (Xen event channel), xenstore shared storage, and the vchan communication protocol. With their help, the basic components of qrexec and qubes-rpc are implemented, and application services - redirecting audio or USB, transferring files or clipboard contents, executing commands and launching applications. It is possible to set policies that allow you to limit the services available on the VM. The figure below shows an example of the procedure for initializing the interaction of two VMs.
Thus, work in the VM is performed without using the network, which allows you to fully use stand-alone VMs to avoid information leakage. For example, this is how the separation of cryptographic operations (PGP / SSH) is implemented when private keys are used in isolated VMs and do not go beyond them.
Templates, applied and disposable VMs
All user work in Qubes is done in virtual machines. The main host system is used to manage their operation and visualization. The OS is installed with a base set of template-based virtual machines (TemplateVM). Such a template is a Linux VM based on the Fedora or Debian distribution, with installed and configured integration tools, selected system and user partitions. Installing and updating software is done by a regular package manager (dnf or apt) from configured repositories with mandatory digital signature verification (GnuPG). The purpose of such VMs is to ensure trust in the application VMs launched on their basis.
The applied VM (AppVM) at startup uses a snapshot of the system partition of the corresponding VM template, and after completion it deletes this snapshot without saving changes. The data required by the user is stored in a user partition unique for each application VM, which is mounted in the home directory.
It can be useful from a security point of view to use disposable VMs. Such a VM is created on the basis of a template at the time of start and starts with one goal - to execute one application, shutting down after it is closed. Disposable VMs can be used to open suspicious files whose contents may lead to the exploitation of specific application vulnerabilities. The ability to run a disposable VM is integrated into the file manager (Nautilus) and mail client (Thunderbird).
Windows VM can also be used to create a template and a one-time VM, for this the user profile is transferred to a separate section. In our version, such a template will be used by the user for administration and application installation tasks. Based on the template, several application VMs will be created - with limited network access (standard sys-firewall capabilities) and without network access at all (no virtual network device is created). To work in these VMs, all changes and applications installed in the template will be available, and even in the case of the introduction of bookmark programs, they will not have access to network access for compromise.
Fight for Windows
The features described above are the basis of Qubes and work quite stably, the difficulties begin with Windows. To integrate Windows, you need to use the Qubes Windows Tools (QWT) guest toolset, which includes drivers for working with Xen, the qvideo driver, and a set of utilities for information exchange (file transfer, clipboard). The installation and configuration process is documented in detail on the project website, so we will share our application experience.
The main difficulty is essentially the lack of support for the developed tools. The Key Developers (QWT) appear to be unavailable and the Windows integration project is awaiting a lead developer. Therefore, first of all, it was necessary to evaluate the performance and make an understanding of the possibility of supporting it, if necessary, independently. The most difficult to develop and debug is the graphics driver, which emulates a video adapter and a display for imaging in shared memory, allowing you to display the entire desktop or the application window itself in the host system window. During the analysis of the driver, we adapted the code for assembly in a Linux environment and worked out a debugging scheme between two Windows guest systems. At the crossbuild stage, we made several changes that make it easier for us, mainly in terms of the "silent" installation of utilities, and also eliminated annoying performance degradation during prolonged work in the VM. We have presented the results of our work in a separate , thus not for long Qubes Lead Developer.
The most critical step in terms of guest system stability is the launch of Windows, here you can see the familiar blue screen (or not even see it). For most of the identified errors, various workarounds were found - abandoning Xen block device drivers, turning off VM memory balancing, fixing network settings, and minimizing the number of cores. Our guest tools build installs and runs on a fully updated Windows 7 and Windows 10 (excluding qvideo).
When moving from a real environment to a virtual one, there is a problem with activating Windows when using pre-installed OEM versions. Such systems use activation based on licenses registered in the UEFI of the device. For correct processing of activation, it is necessary to translate one of the ACPI sections of the host system as a whole (SLIC table) into the guest system and slightly edit others, prescribing the manufacturer. Xen allows you to customize the ACPI content of additional tables, but without modifying the main ones. A patch from a similar OpenXT project, which was adapted for Qubes, helped with the solution. The fixes seemed useful not only to us and were translated into the main Qubes repository and the Libvirt library.
The obvious disadvantages of the Windows integration tools are the lack of support for sound, USB devices, and the complexity of working with media, since there is no GPU hardware support. But the above does not prevent the use of a VM to work with office documents, does not prevent the launch of specific corporate applications.
The requirement to switch to operating mode without a network or with a limited network after creating a Windows VM template was performed by creating the appropriate configurations of application VMs, and the ability to selectively connect removable media was also solved by standard OS tools - when connected, they are available in the system VM sys-usb, from where they can be " forwarded" to the required VM. The user's desktop looks something like this.
The final version of the system was positively (as far as such a comprehensive solution allows) accepted by users, and the standard system tools made it possible to expand the application to a user's mobile workplace with access via VPN.
Instead of a conclusion
Virtualization generally reduces the risk of using Windows systems left unsupported - it does not force compatibility with new hardware, it allows you to exclude or control access to the system over a network or through connected devices, it allows you to create a one-time run environment.
Qubes OS, based on the idea of isolation through virtualization, helps to use these and other security mechanisms. From the outside, many see Qubes primarily as a desire for anonymity, but it is a useful system both for engineers, who often combine projects, infrastructures and access secrets to them, and for security researchers. Separation of applications, data and formalization of their interaction are the initial steps of threat analysis and protection system design. This division helps to structure information and reduce the likelihood of errors due to the human factor - haste, fatigue, etc.
Currently, the main emphasis in development is on expanding the functionality of Linux environments. Version 4.1 is being prepared for release, which will be based on Fedora 31 and include up-to-date versions of the key Xen and Libvirt components. It is worth noting that Qubes is created by professionals in the field of information security, who always release updates promptly if new threats or errors are detected.
Afterword
One of the experimental features we are developing allows you to create a VM with support for guest access to the GPU based on Intel GVT-g technology, which allows you to use the capabilities of the graphics adapter and significantly expand the scope of the system. At the time of this writing, this functionality works for Qubes 4.1 test builds, and is available on .
Source: habr.com