Iran protesters take to the streets in third day of demos over plane
Australian prime minister's approval rating goes up in flames
Thai elephants march in silence for Australian bushfires

Source: Blockchain.info
0000000000000000000444803ca23cffb65ea59fb0afef4065b2ea897a03e120


Footnotes
----------

[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this
canary in the qubes-secpack.git repo, and (2) via digital signatures
on the corresponding qubes-secpack.git repo tags. [2]

[2] Don't just trust the contents of this file blindly! Verify the
digital signatures!

Xen Project Design and Developer Summit: Registration and CFP Open Now!
https://xenproject.org/2020/01/17/xen-project-design-and-developer-summit-registration-and-cfp-open-now/

Starting today, registration and Call for Proposals officially opens for the Xen Project Developer & Design Summit. This year’s Summit, taking place from June 2nd through the 4th at the...

Qubes OS 4.0.3 has been released!
https://www.qubes-os.org/news/2020/01/23/qubes-4-0-3/

We’re pleased to announce the release of Qubes 4.0.3! This is the third
stable point release of Qubes 4.0. While it includes only minimal
changes over 4.0.3-rc1 and 4.0.2, it includes many updates over the
initial 4.0 release, in particular:

All 4.0 dom0 updates to date
Fedora 30 TemplateVM
Debian 10 TemplateVM
Whonix 15 Gateway and Workstation TemplateVMs
Linux kernel 4.19 by default
Qubes 4.0.3 is available on the Downloads (https://www.qubes-os.org/downloads/) page.

What is a point release?

A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating it results in the same system as installing
Qubes 4.0.3.

What should I do?

If you installed Qubes 4.0, 4.0.1, 4.0.2, or 4.0.3-rc1 and have fully
updated (https://www.qubes-os.org/doc/updating-qubes-os/), then your system is already equivalent to a Qubes 4.0.3
installation. No further action is required.

Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.3 ISO makes this more convenient
and secure, since it bundles all Qubes 4.0 updates to date.

Note: The Qubes 4.0.3 ISO will not fit on a single-layer DVD (for
the technical details underlying this, please see issue #5367 (https://github.com/QubesOS/qubes-issues/issues/5367)).
Instead, we recommend copying the ISO onto a sufficiently large USB
drive (https://www.qubes-os.org/doc/installation-guide/#copying-the-iso-onto-the-installation-medium). However, if you would prefer to use optical media, we
suggest selecting a dual-layer DVD or Blu-ray disc.

Thank you to all the release candidate users for testing this release
and reporting issues (https://www.qubes-os.org/doc/reporting-bugs/)!

XCP-ng Joins the Xen Project as an Incubation Project
https://xenproject.org/2020/01/28/xcp-ng-joins-the-xen-project-as-an-incubation-project/

Today, the Xen Project is happy to welcome XCP-ng as an incubation project. XCP-ng is a fully open-source virtualization platform and is a result of the massive cooperation between individuals...

Saying Goodbye to Lars Kurth: Open Source Advocate and Friend
https://xenproject.org/2020/01/31/saying-goodbye-to-lars-kurth-open-source-advocate-and-friend/

It is with a heavy heart that the Xen Project community says goodbye to Advisory Board Chair, Lars Kurth. Lars passed away earlier this week, leaving a hole in our...

Services for Lars Kurth
https://xenproject.org/2020/02/04/services-for-lars-kurth/

A funeral for Lars Kurth will be held on Friday, 7 February, at 11:45 am. Everyone is welcome to attend. Location and further information here: http://larskurth.muchloved.com

Xen Project is Participating in May 2020 to August 2020 Outreachy Internships Round
https://xenproject.org/2020/02/20/xen-project-is-participating-in-may-2020-to-august-2020-outreachy-internships-round/

The Xen Project is excited to be participating in the Outreachy internship program which supports diversity in free and open source software. The Xen Project’s participation in this round is...

Unikraft: Building Powerful Unikernels Has Never Been Easier!
https://xenproject.org/2020/02/21/xen-project-is-participating-in-may-2020-to-august-2020-outreachy-internships-round-2/

Two years ago, the Xen Project introduced Unikraft (http://unikraft.org) as an incubation project. Over the past two years, the Unikraft project has seen some great momentum. Since the last release,...

NitroPad X230 passes hardware certification for Qubes 4.0!
https://www.qubes-os.org/news/2020/03/04/nitropad-x230-qubes-certification/

It is our pleasure to announce that the NitroPad X230 (https://shop.nitrokey.com/shop/product/nitropad-x230-67) has become the
second Qubes-certified Laptop (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptop-insurgo-privacybeast-x230) for Qubes 4.0! This makes
Nitrokey (https://www.nitrokey.com/) the first vendor in Europe to have a product pass Qubes
hardware certification.

What is Qubes Certified Hardware?

Qubes Certified Hardware (https://www.qubes-os.org/doc/certified-hardware/) is hardware that has been certified by the
Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0,
in order to achieve certification, the hardware must satisfy a rigorous
set of requirements (https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements), and the vendor must commit to offering customers
the very same configuration (same motherboard, same screen, same BIOS
version, same Wi-Fi module, etc.) for at least one year.

Qubes-certified Laptops (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptop-insurgo-privacybeast-x230), in particular, are regularly tested
by the Qubes developers to ensure compatibility with all of Qubes’
features. The developers test all new major versions and updates to
ensure that no regressions are introduced.

It is important to note, however, that Qubes Hardware Certification
certifies only that a particular hardware configuration is supported
by Qubes. The Qubes OS Project takes no responsibility for any
manufacturing or shipping processes, nor can we control whether physical
hardware is modified (whether maliciously or otherwise) en route to
the user. (However, see below for information about how the Insurgo team
mitigates this risk.)

About the NitroPad X230

The NitroPad X230 (https://shop.nitrokey.com/shop/product/nitropad-x230-67) offers users unprecedented control over the security
of their hardware. Key features include:


Tamper detection through measured boot with Coreboot (https://www.coreboot.org/), Heads (https://github.com/osresearch/heads/), and
Nitrokey USB hardware, including support for Anti Evil Maid (AEM) (https://www.qubes-os.org/doc/anti-evil-maid/).


Deactivated Intel Management Engine (https://libreboot.org/faq.html#intelme)


User-replaceable cryptogrpahic keys


Included Nitrokey USB key


Professional ThinkPad hardware based on the ThinkPad X230 (https://www.thinkwiki.org/wiki/Category:X230).


Security-conscious shipping to mitigate against third-party
interdiction (https://en.wikipedia.org/wiki/Interdiction).

For further details, please see the original NitroPad announcement (https://www.nitrokey.com/news/2020/nitropad-secure-laptop-unique-tamper-detection).

How to get one

Please see the NitroPad X230 (https://shop.nitrokey.com/shop/product/nitropad-x230-67) on the Nitrokey website (https://www.nitrokey.com/) for
more information.

XSA-315 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2020/03/12/xsa-315-qubes-not-affected/

The Xen Project has published Xen Security Advisory 315 (XSA-315).
This XSA does not affect the security of Qubes OS, and no user
action is necessary.

This XSA has been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):

https://www.qubes-os.org/security/xsa/#315

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 for an effective approach to a GUI domain: how the GUI protocol relied on dom0-level privileges and how managing anything in the system required dom0-level access to the hypervisor.

GUI Protocol

Detailed documentation of the current GUI protocol is available here (https://www.qubes-os.org/doc/gui/). In brief, it consists of a GUI agent and a GUI daemon. The GUI agent runs in a qube and connects to the GUI daemon in dom0, passing a list of memory addresses of window buffers. As the GUI daemon is running in dom0, with privileged access to, well, everything, it can just map any page of any qube’s memory. You can see why this might be a bit worrying: Access to memory is power, thus dom0 is all-powerful. It would be far worse if we tried to duplicate this architecture and make our GUI domain a qube with the same memory-related privileges. It would just result in two dom0s. Rather than being reduced, the attack surface would be increased.

The upcoming 4.1 release changes this protocol to a more flexible form. It will no longer use direct memory addresses, but an abstract mechanism in which the qube has to explicitly allow access to a particular memory page. In our current implementation — under Xen — we use the grant tables mechanism, which provides a separate memory allocation API and allows working on grants and not directly on memory pages. Other implementations will also be possible: whether for another hypervisor (e.g. KVM) or for a completely different architecture not based on shared memory (e.g. directly sending frames to another machine).

Managing the system

The second problem — system management — is actually partially solved already in Qubes 4.0. Administrative actions such as creating, changing or starting qubes can be handled via qrexec calls and controlled via qrexec policy. You can read more about the Admin API, one of the big changes in Qubes 4.0 that made all this possible here (https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/).

Currently, in Qubes 4.0, dom0 handles all these administrative actions. However, in order to avoid unpleasant surprises and to prepare the architecture for the GUI domain, we already always perform them via Admin API. At the design level, dom0 is no longer a special and different case: It makes qrexec calls like any other qube.

There’s an interesting, subtle detail here: We just accepted dom0 being able to run anything in any way inside other qubes. But if we want to implement a more contained and less-privileged GUI domain, it would defeat part of its purpose to just permit it to run any sort of qvm-run do-what-I-want in any of the managed qubes. Qubes 4.0 introduces a special qubes.StartApp qrexec service that runs only applications defined inside the target qube (currently defined via .desktop files in Linux and .lnk files in Windows, placed in predetermined directories). This mechanism allows a qube to explicitly define “what the GUI domain can execute inside me,” and not just hand over all the power to the managing domain. This also makes it possible to define allowed applications using the qrexec policy!

Other issues

Actually implementing a GUI domain (more details below) revealed a lot of minor problems that require some handling. Unsurprisingly, it turns out a modern operating system encourages a very close relationship between whatever part of it deals with graphical display and all the rest of the hardware.

Power management has numerous vital graphical tools that need some kind of access to underlying hardware. From a battery level widget to laptop power management settings, those innocuous GUI tools would like to have a surprisingly broad access to the system itself. Even suspend and shutdown need special handling. In Qubes 4.0, we could just turn off dom0 and know the rest of the system would follow, but it is no longer so simple with a non-privileged GUI domain in the

picture.

Keyboard and user input need to be carefully proxied to the GUI domain to enable us to actually use the system. The existing InputProxy system needs to be expanded to ferry information from the USB domain (in the case of USB keyboards and mice) and from dom0 (in some other cases, like PS/2 keyboards) to the GUI domain.

The current state of those minor (minor in comparison to broad, architecture-level changes, but by no means unimportant) issues is tracked here (https://github.com/QubesOS/qubes-issues/issues/4186).

How can the GUI domain actually work?

GPU passthrough: the perfect-world desktop solution

In the perfect world, we could simply connect the graphics card to the VM as a PCI device and enjoy a new, more comfortable level of separation. Unfortunately, the world of computer hardware is very far from a perfect one. This solution works only very rarely. For most graphics cards, it just fails, although some success has been observed on some AMD cards. Even if, in theory, the architecture supports GPU passthrough, many implementations rely on various hardware quirks and peculiarities absent when there is no direct access to the underlying system. For example, the video BIOS (the code that the GPU provides to the system to initialize itself) in many cases assumes that it is running with full privileges and tries to access various registers and memory areas not available to (or virtualized in) VMs.

And all that is without even approaching issues with multiple graphical cards, multiple outputs or suspending the host; or the fact that some hardware manufactures (like NVIDIA) attempt to block GPU passthrough for some of their products.

At the moment, a group of very brave university students are working on the basic GPU passthrough case as their bachelor’s degree project. We wish them a lot of luck in this difficult endeavor!

Virtual server: the perfect remote solution

Instead of wrestling with the hardware problems, GUI domain could instead connect to a virtual graphical server such as FreeRDP or VNC. This server could be accessible from anywhere on the network (in practice, it should be secured with at least a VPN, as bugs allowing unauthorized users access could be very dangerous), allowing for a Qubes Server hosting many separate sets of qubes used by different users, still maintaining comfortable separation between the qubes and the users. Qrexec policy allows the administrator to comfortably manage this solution: Every GUI domain can have its own set of privileges, managed qubes, Disposable VM permissions etc.

Surprisingly, a virtual server solution does actually work with the current state of Qubes as of the 4.1 developer preview build, and it allows us to bypass the dreaded GPU passthrough complications. The only not-so-small problem is that it does not actually handle our main use case: Qubes running locally on a single machine. This is because it uses the network to expose the GUI, and the place where the local display is handled (dom0) doesn’t have access to the network.

The compromise solution