-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear Qubes Community,
A new article has just been published on the Qubes website:
"Qubes Architecture Next Steps: The GUI Domain"
by Marek Marczykowski-Górecki & Marta Marczykowska-Górecka
https://www.qubes-os.org/news/2020/03/18/gui-domain/
The original Markdown source is included below:
- ---
layout: post
title: "Qubes Architecture Next Steps: The GUI Domain"
categories: articles
author: Marek Marczykowski-Górecki, Marta Marczykowska-Górecka
image: /attachment/wiki/posts/guivm-hybrid.png
- ---
It has been some time since the last design post about Qubes. There
have been some [big changes
happened](https://www.qubes-os.org/news/2018/10/25/thank-you-joanna/),
and it took us a little while to find people best suited to write
these articles. But, as you can see, the ~~victims~~ volunteers have
been found. The team has been hard at work on the changes that are
coming in 4.1, and we want to tell you more about them.
One of the Big Things coming soon, in Qubes 4.1, is the first public
version of the GUI domain: the next step in decoupling the graphical
hardware, the display and management, and the host system. Very
briefly, the GUI domain is a qube separate from dom0 that handles all
the display-related tasks and some system management.
## Why make a GUI domain at all?
One of the biggest security concerns at the moment for Qubes is how
much power is in dom0. Once a person has access to it, they can do
anything: and while we separate it quite effectively from what is
running inside application qubes, dom0 is still a big, bloated and
complex domain that performs many disparate functions. It handles
managing other domains, display and graphical interfaces, multiple
devices (including audio devices), memory and disk management, and so on
.
We mitigate many of the GUI-related risks (like the powers wielded by
the window manager, or the fact that huge, complex libraries such as
Qt/Gtk are always an increased attack surface) through
compartmentalization: Applications in VMs can't talk to GUI toolkits
in dom0 other than through a very limited Qubes-GUI protocol, and GUI
toolkits in application VMs can't talk directly to dom0's X server.
Moreover, dom0 is responsible for drawing the colored window borders
the represent trust levels, so compromised VMs can't spoof them.
Nonetheless, having a GUI in dom0 at all is, at best, a source of many
dangerous temptations. It's far too easy to use it to access untrusted
(and thus potentially dangerous data), for example by mounting a disk
from a qube into dom0. Even browsing relaxing landscapes as desktop
wallpapers can expose dom0 to numerous vulnerabilities that
intermittently appear in image-processing libraries.
Furthermore, while in theory dom0 is isolated from the outside world,
some graphical devices (e.g. displays connected via HDMI or DVI) offer
two-way communication, which threatens this isolation and makes it
harder to maintain. If a malicious device (rather than the user's
trusted monitor) were to be connected to one of these ports, it could
inject data that could be processed inside of dom0. As long as
graphical devices are in dom0, they also cannot be safely proxied to
other domains. This is because the various solutions to multiplexing
access to the GPU at the GPU/driver level (which would expose the
"full" GPU to a VM) are orders of magnitude more complex than running
display drivers in just one place. We consider this added complexity
too risky to put it in dom0. Errors in the drivers could expose dom0
to an attack, and attacks on dom0 are the biggest threat to the Qubes
security model.
The current model, in which the GUI and administrative domains are
both within dom0, is also problematic from a management point of view.
The way existing user-based privilege control works in most modern
systems is one of the reasons why we need Qubes at all: It provides
far too little separation, and root exploits seem to be inescapable in
a system as monolithic as Linux. Separating the GUI domain from dom0
allows us to manage its access to the underlying system.
This has obvious uses in an organizational context, allowing for
(possibly remotely) managed Qubes installations, but even in a
personal computer context it is often extremely useful to have
multiple user accounts with truly separate permissions and privileges.
Perhaps you would like to create a guest account for any friend who
needs to borrow your computer for a moment, and allow that account to
create Disposable VMs, but not to create normal qubes and not to
access other users' qubes. It becomes possible when the GUI domain is
decoupled from dom0. All kinds of kiosk modes, providing safer
environments for less-technical users who prefer to be sure they
cannot break something accidentally, multi-user environments --- they
all become possible.
## What needs to be ready?
There were two big issues in the previous Qubes architecture that
needed to be handled
