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
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
While GPU passthrough is a work-in-progress and a server-based solution is impractical, there is a compromise solution: Dom0 can keep the X Server and graphics drivers but use them to run only a single, simple application — a full-screen proxy for the GUI domain’s graphical server (an approach similar to the one used by OpenXT). We could even use VNC for this, but luckily, there is another solution based on protocols that have already been tested and implemented. Through the GUI protocol’s shared memory and a Xephyr server on the dom0 side, we can achieve something of a GUI protocol nesting.
Like many compromises, it is far from completely satisfying. The biggest problem is that it still keeps clutter (in the form of drivers and X Server) in dom0 — much less clutter given that huge libraries and desktop environments no longer need to live there, but still clutter. Many of the GPU passthrough problems are still here: Power management will require some finesse, and multi-monitor setups are still untested. (They may require us to extend some of Xephyr’s functionality.)
However, we can be pretty sure there will never be a GPU passthrough solution that works on every system. It is not just about the complexity of the problem and the multitude of GPU products available. As mentioned above, some manufacturers intentionally obstruct GPU passthrough in their graphics cards, so it is likely that some hardware configurations will never have full support. This is why the compromise solution will be available as a fallback even once more robust GPU passthrough is developed.
Surprise dependency: audio
As far as system architecture goes, audio systems are a completely separate set of processes, communication channels and tools — but this is only the theory. In practice, audio is very tightly connected to GUI in most modern systems. On Qubes 4.0, pulseaudio tools start together with GUI tools both in dom0 and in application qubes.
While audio drivers and tools are not nearly as bloated and sprawling as GUI tools, keeping them in dom0 is still suboptimal, and with the move toward a GUI domain, it will become increasingly impossible. Our first step was to see how we could move audio away from dom0: Connect it together with the GPU to the GUI domain and see what breaks. Surprisingly, few things did, and while some hard-coded “connect to dom0 for all of your audio needs” configurations needed to be updated, those changes are already done in Qubes 4.1.
This is not the final solution we would like, though; it would be best to truly decouple audio and GUI, creating a dedicated and separate audio aomain.
Audio Domain
The audio domain will be a separate virtual machine that accesses and proxies audio card access. This way, we can not only remove audio from dom0 (making it smaller and less exposed) but also from the GUI domain (which, by virtue of being still quite privileged, should also have as little additional capabilities as possible).
All the complex audio subsystems, from pulseaudio (which controls volume for each domain) to audio mixers and microphones, would reside in the audio domain. It will have its own set of particular privileges. For example, due to the current audio hardware architecture, the audio domain will have access to the complete audio intput and output, but isolating them in a separate domain will significantly reduce the attack surface. Keeping audio in the same domain as the keyboard or screen could, in theory, lead to eavesdropping attacks. In a separate audio domain, all those potentially vulnerable devices are isolated. Even Bluetooth audio devices (like headphones) could finally be used securely, without exposing the whole system to attack.
What will actually be in Qubes 4.1
Most of code to handle the compromise solution is either already merged into the Qubes master branch or currently awaits final merging and will be available in Qubes 4.1. However, it will not be the default.
Like many compromises, it is far from completely satisfying. The biggest problem is that it still keeps clutter (in the form of drivers and X Server) in dom0 — much less clutter given that huge libraries and desktop environments no longer need to live there, but still clutter. Many of the GPU passthrough problems are still here: Power management will require some finesse, and multi-monitor setups are still untested. (They may require us to extend some of Xephyr’s functionality.)
However, we can be pretty sure there will never be a GPU passthrough solution that works on every system. It is not just about the complexity of the problem and the multitude of GPU products available. As mentioned above, some manufacturers intentionally obstruct GPU passthrough in their graphics cards, so it is likely that some hardware configurations will never have full support. This is why the compromise solution will be available as a fallback even once more robust GPU passthrough is developed.
Surprise dependency: audio
As far as system architecture goes, audio systems are a completely separate set of processes, communication channels and tools — but this is only the theory. In practice, audio is very tightly connected to GUI in most modern systems. On Qubes 4.0, pulseaudio tools start together with GUI tools both in dom0 and in application qubes.
While audio drivers and tools are not nearly as bloated and sprawling as GUI tools, keeping them in dom0 is still suboptimal, and with the move toward a GUI domain, it will become increasingly impossible. Our first step was to see how we could move audio away from dom0: Connect it together with the GPU to the GUI domain and see what breaks. Surprisingly, few things did, and while some hard-coded “connect to dom0 for all of your audio needs” configurations needed to be updated, those changes are already done in Qubes 4.1.
This is not the final solution we would like, though; it would be best to truly decouple audio and GUI, creating a dedicated and separate audio aomain.
Audio Domain
The audio domain will be a separate virtual machine that accesses and proxies audio card access. This way, we can not only remove audio from dom0 (making it smaller and less exposed) but also from the GUI domain (which, by virtue of being still quite privileged, should also have as little additional capabilities as possible).
All the complex audio subsystems, from pulseaudio (which controls volume for each domain) to audio mixers and microphones, would reside in the audio domain. It will have its own set of particular privileges. For example, due to the current audio hardware architecture, the audio domain will have access to the complete audio intput and output, but isolating them in a separate domain will significantly reduce the attack surface. Keeping audio in the same domain as the keyboard or screen could, in theory, lead to eavesdropping attacks. In a separate audio domain, all those potentially vulnerable devices are isolated. Even Bluetooth audio devices (like headphones) could finally be used securely, without exposing the whole system to attack.
What will actually be in Qubes 4.1
Most of code to handle the compromise solution is either already merged into the Qubes master branch or currently awaits final merging and will be available in Qubes 4.1. However, it will not be the default.
The GUI domain will be an experimental feature. We will provide a salt formula to easily configure it for anyone who wants to try it out and play around with it. Our main goal is to test everything we can test without GPU passthrough in order to reach a state in which the aforementioned more minor problems are handled. Then we’ll be ready for a GPU passthrough solution once it is developed (which is being worked on separately).
The GUI domain is currently ready for Linux-based qubes and for fullscreen HVMs, not for the Windows GUI agent. At the moment, nobody on our team is the sort of Windows wizard who could do that, so Qubes 4.1 will not have GUI domain support for for the Windows GUI agent. (Coincidentally, this is the same reason that the GUI agent is not compatible with Windows 10 at the moment. If you, dear reader, would like to work with us on Windows 10 GUI agent and GUI domain support, please let us know!)
Currently, many parts of the Qubes architecture assume a singular target GUI domain (or audio domain) for every qube. There may be multiple GUI domains in the system, but each qube can only use one of them. We do not plan to change this in the foreseeable future.
Plans for the future
Introducing the GUI domain opens up a lot of interesting new possibilities. First and foremost, even in the middle-of-the-road, painful-compromise solution, dom0 will still be much, much smaller (no desktop managers or huge graphical libraries), thus it can be much more easily ported to another distribution.
A smaller dom0 could also be placed completely in RAM, making the whole disk controller and storage subsystem independent from it and possibly isolated in its own storage domain, as described in the Qubes Architecture Specification (https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf) only 10 years ago. Now we’re finally moving closer to this goal!
Finally, decoupling support for VNC and other remote desktop capabilities opens the door to various server-based solutions in which Qubes can run on a remote server, and we can delegate some or all of our domains to other machines (potentially with faster harder and more resources). This is a another step toward Qubes Air (https://www.qubes-os.org/news/2018/01/22/qubes-air/).
The GUI domain is currently ready for Linux-based qubes and for fullscreen HVMs, not for the Windows GUI agent. At the moment, nobody on our team is the sort of Windows wizard who could do that, so Qubes 4.1 will not have GUI domain support for for the Windows GUI agent. (Coincidentally, this is the same reason that the GUI agent is not compatible with Windows 10 at the moment. If you, dear reader, would like to work with us on Windows 10 GUI agent and GUI domain support, please let us know!)
Currently, many parts of the Qubes architecture assume a singular target GUI domain (or audio domain) for every qube. There may be multiple GUI domains in the system, but each qube can only use one of them. We do not plan to change this in the foreseeable future.
Plans for the future
Introducing the GUI domain opens up a lot of interesting new possibilities. First and foremost, even in the middle-of-the-road, painful-compromise solution, dom0 will still be much, much smaller (no desktop managers or huge graphical libraries), thus it can be much more easily ported to another distribution.
A smaller dom0 could also be placed completely in RAM, making the whole disk controller and storage subsystem independent from it and possibly isolated in its own storage domain, as described in the Qubes Architecture Specification (https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf) only 10 years ago. Now we’re finally moving closer to this goal!
Finally, decoupling support for VNC and other remote desktop capabilities opens the door to various server-based solutions in which Qubes can run on a remote server, and we can delegate some or all of our domains to other machines (potentially with faster harder and more resources). This is a another step toward Qubes Air (https://www.qubes-os.org/news/2018/01/22/qubes-air/).
XenProject Developer and Design Summit: Update in light of COVID-19
https://xenproject.org/2020/03/26/xenproject-developer-and-design-summit-update-in-light-of-covid-19/
The past several weeks have been an uncertain time globally. In the spirit of transparency, I wanted to update our community on plans for our annual developer conference, The Xen...
https://xenproject.org/2020/03/26/xenproject-developer-and-design-summit-update-in-light-of-covid-19/
The past several weeks have been an uncertain time globally. In the spirit of transparency, I wanted to update our community on plans for our annual developer conference, The Xen...
Qubes Canary #23
https://www.qubes-os.org/news/2020/04/15/canary-23/
We have published Qubes Canary #23. The text of this canary is
reproduced below. This canary and its accompanying signatures will
always be available in the Qubes Security Pack (qubes-secpack).
View Qubes Canary #23 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-023-2020.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #23 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is April 9, 2020.
2. There have been 56 Qubes Security Bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
two weeks of September 2020. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised. This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.
The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.
Proof of freshness
-------------------
Thu, 09 Apr 2020 01:16:49 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Politicians Call for Fewer Climate Protections During Coronavirus Crisis
Coronavirus: En refusant les eurobonds, l’Allemagne fait preuve d’égoïsme, d’obstination et de lâcheté
Coronavirus: El rechazo alemán de los eurobonos es insolidario, mezquino y cobarde
New York City: Eight Days in the New Capital of Corona
Coronavirus: Il rifiuto tedesco degli Eurobond è non solidale, gretto e vigliacco
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Saudi Arabia, Hit by Coronavirus, Declares Cease-Fire in Yemen: Live Updates
Saudi Arabia Declares Cease-Fire in Yemen, Citing Fears of Coronavirus
Eight U.K. Doctors Died From Coronavirus. All Were Immigrants.
Some of Europe, ‘Walking a Tightrope,’ Will Loosen Coronavirus Restrictions
China’s Coronavirus Battle Is Waning. Its Propaganda Fight Is Not.
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Coronavirus: WHO chief urges end to 'politicisation' of virus
Bernie Sanders suspends presidential campaign
Yemen: Saudi-led coalition announces ceasefire
Woman who revealed Clinton-Lewinsky scandal dies
Coronavirus: How Russia's ballet wasn't shut down despite lockdown
Source: Reuters: World News (http://feeds.reuters.com/reuters/worldnews)
https://www.qubes-os.org/news/2020/04/15/canary-23/
We have published Qubes Canary #23. The text of this canary is
reproduced below. This canary and its accompanying signatures will
always be available in the Qubes Security Pack (qubes-secpack).
View Qubes Canary #23 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-023-2020.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #23 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is April 9, 2020.
2. There have been 56 Qubes Security Bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
two weeks of September 2020. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised. This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.
The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.
Proof of freshness
-------------------
Thu, 09 Apr 2020 01:16:49 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Politicians Call for Fewer Climate Protections During Coronavirus Crisis
Coronavirus: En refusant les eurobonds, l’Allemagne fait preuve d’égoïsme, d’obstination et de lâcheté
Coronavirus: El rechazo alemán de los eurobonos es insolidario, mezquino y cobarde
New York City: Eight Days in the New Capital of Corona
Coronavirus: Il rifiuto tedesco degli Eurobond è non solidale, gretto e vigliacco
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Saudi Arabia, Hit by Coronavirus, Declares Cease-Fire in Yemen: Live Updates
Saudi Arabia Declares Cease-Fire in Yemen, Citing Fears of Coronavirus
Eight U.K. Doctors Died From Coronavirus. All Were Immigrants.
Some of Europe, ‘Walking a Tightrope,’ Will Loosen Coronavirus Restrictions
China’s Coronavirus Battle Is Waning. Its Propaganda Fight Is Not.
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Coronavirus: WHO chief urges end to 'politicisation' of virus
Bernie Sanders suspends presidential campaign
Yemen: Saudi-led coalition announces ceasefire
Woman who revealed Clinton-Lewinsky scandal dies
Coronavirus: How Russia's ballet wasn't shut down despite lockdown
Source: Reuters: World News (http://feeds.reuters.com/reuters/worldnews)
WHO head defends handling of coronavirus pandemic against Trump criticism
Brazil turns to local industry to build ventilators as China orders fall through
Ecuador's Moreno calls for probe into handling of corpses in coronavirus outbreak
Australian police take 'black box' off cruise ship in coronavirus homicide probe
Mexico registers 3,181 cases of coronavirus and 174 deaths
Source: Blockchain.info
0000000000000000000d88e12aee57e8aa90ceea6b74b962a39427c5f2fdb6d0
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!
Brazil turns to local industry to build ventilators as China orders fall through
Ecuador's Moreno calls for probe into handling of corpses in coronavirus outbreak
Australian police take 'black box' off cruise ship in coronavirus homicide probe
Mexico registers 3,181 cases of coronavirus and 174 deaths
Source: Blockchain.info
0000000000000000000d88e12aee57e8aa90ceea6b74b962a39427c5f2fdb6d0
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!
XSAs 313, 314, 316, and 318 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2020/04/15/xsa-313-314-316-318-qubes-not-affected/
The Xen Project has published Xen Security Advisories 313, 314, 316,
and 318 (XSA-313, XSA-314, XSA-316, and XSA-318, respectively). These
XSAs do not affect the security of Qubes OS, and no user action is
necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#313
https://www.qubes-os.org/security/xsa/#314
https://www.qubes-os.org/security/xsa/#316
https://www.qubes-os.org/security/xsa/#318
https://www.qubes-os.org/news/2020/04/15/xsa-313-314-316-318-qubes-not-affected/
The Xen Project has published Xen Security Advisories 313, 314, 316,
and 318 (XSA-313, XSA-314, XSA-316, and XSA-318, respectively). These
XSAs do not affect the security of Qubes OS, and no user action is
necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#313
https://www.qubes-os.org/security/xsa/#314
https://www.qubes-os.org/security/xsa/#316
https://www.qubes-os.org/security/xsa/#318
If you haven’t yet, Join our wonderful (Unofficial) Support group!
https://news.1rj.ru/str/joinchat/B8FHpkEToMfgdREGV7wzRQ
https://news.1rj.ru/str/joinchat/B8FHpkEToMfgdREGV7wzRQ
Telegram
QubesOS Chat
(Community Support)
Alternative community instead of online forum and discord.
@QubesOS
>No spam/ads/NSFW/shit posts/spam bots
>Respect others
>Stay on topic
>Be transparent
If you need help ask!
Rules are enforced with ban or restrictions.
Alternative community instead of online forum and discord.
@QubesOS
>No spam/ads/NSFW/shit posts/spam bots
>Respect others
>Stay on topic
>Be transparent
If you need help ask!
Rules are enforced with ban or restrictions.
Fedora 30 approaching EOL, Fedora 31 TemplateVM available, Fedora 32 TemplateVM in testing
https://www.qubes-os.org/news/2020/04/30/fedora-31-template-available/
This announcement includes several updates regarding Fedora TemplateVMs.
Fedora 30 approaching EOL
With the release of Fedora 32 on April 28, Fedora 30 is expected to
reach EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)) on May 26, 2020.
Fedora 31 TemplateVM available
A new Fedora 31 TemplateVM is now available for both Qubes 4.0 and 4.1.
Instructions are available for upgrading Fedora TemplateVMs (https://www.qubes-os.org/doc/template/fedora/upgrade/). We also
provide a fresh Fedora 31 TemplateVM package through the official Qubes
repositories, which you can get with the following commands (in dom0).
Standard (https://www.qubes-os.org/doc/templates/fedora/) Fedora 31 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-31
Minimal (https://www.qubes-os.org/doc/templates/minimal/) Fedora 31 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-31-minimal
After upgrading to a Fedora 31 TemplateVM, please remember to switch all
qubes that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
Fedora 32 TemplateVM in testing
For advanced users, a new Fedora 32 TemplateVM is currently available in
the qubes-templates-itl-testing repository for both Qubes 4.0 and 4.1.
We would greatly appreciate testing and feedback (https://www.qubes-os.org/doc/testing/#providing-feedback) from the community
regarding this template.
https://www.qubes-os.org/news/2020/04/30/fedora-31-template-available/
This announcement includes several updates regarding Fedora TemplateVMs.
Fedora 30 approaching EOL
With the release of Fedora 32 on April 28, Fedora 30 is expected to
reach EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)) on May 26, 2020.
Fedora 31 TemplateVM available
A new Fedora 31 TemplateVM is now available for both Qubes 4.0 and 4.1.
Instructions are available for upgrading Fedora TemplateVMs (https://www.qubes-os.org/doc/template/fedora/upgrade/). We also
provide a fresh Fedora 31 TemplateVM package through the official Qubes
repositories, which you can get with the following commands (in dom0).
Standard (https://www.qubes-os.org/doc/templates/fedora/) Fedora 31 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-31
Minimal (https://www.qubes-os.org/doc/templates/minimal/) Fedora 31 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-31-minimal
After upgrading to a Fedora 31 TemplateVM, please remember to switch all
qubes that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
Fedora 32 TemplateVM in testing
For advanced users, a new Fedora 32 TemplateVM is currently available in
the qubes-templates-itl-testing repository for both Qubes 4.0 and 4.1.
We would greatly appreciate testing and feedback (https://www.qubes-os.org/doc/testing/#providing-feedback) from the community
regarding this template.
Xen Summit 2020 Pivots to a Virtual Experience
https://xenproject.org/2020/05/19/xen-summit-2020-pivots-to-a-virtual-experience/
In light of continued Covid-19 safety concerns, the 2020 XenProject Developer and Design Summit will now be held virtually on July 6-9. As our in-person event shifts to a virtual...
https://xenproject.org/2020/05/19/xen-summit-2020-pivots-to-a-virtual-experience/
In light of continued Covid-19 safety concerns, the 2020 XenProject Developer and Design Summit will now be held virtually on July 6-9. As our in-person event shifts to a virtual...
Qubes awarded MOSS Mission Partners grant!
https://www.qubes-os.org/news/2020/05/22/moss-mission-partners-grant/
We’re proud to announce that the Qubes OS Project has been awarded a
Mozilla Open Source Support (MOSS) (https://www.mozilla.org/en-US/moss/) awards program grant in the amount
of 128,000 USD. This generous one-year grant will fund the work of
Frédéric Pierret (https://www.qubes-os.org/team/#fr%C3%A9d%C3%A9ric-pierret) on making Qubes more robust and stable, as well as
several key parts of Nina Alter (https://www.qubes-os.org/team/#nina-eleanor-alter)’s extensive work on making Qubes more
user-friendly.
There are three separate tracks for MOSS awards. Qubes has been awarded
a grant in the Mission Partners (https://www.mozilla.org/en-US/moss/mission-partners/) track. As Mozilla explains, “The
Mission Partners track supports open source projects that significantly
advance Mozilla’s mission.” It is a great honor for Qubes to be
recognized as such a project, and we’re thrilled by the important work
that this grant will enable.
https://www.qubes-os.org/news/2020/05/22/moss-mission-partners-grant/
We’re proud to announce that the Qubes OS Project has been awarded a
Mozilla Open Source Support (MOSS) (https://www.mozilla.org/en-US/moss/) awards program grant in the amount
of 128,000 USD. This generous one-year grant will fund the work of
Frédéric Pierret (https://www.qubes-os.org/team/#fr%C3%A9d%C3%A9ric-pierret) on making Qubes more robust and stable, as well as
several key parts of Nina Alter (https://www.qubes-os.org/team/#nina-eleanor-alter)’s extensive work on making Qubes more
user-friendly.
There are three separate tracks for MOSS awards. Qubes has been awarded
a grant in the Mission Partners (https://www.mozilla.org/en-US/moss/mission-partners/) track. As Mozilla explains, “The
Mission Partners track supports open source projects that significantly
advance Mozilla’s mission.” It is a great honor for Qubes to be
recognized as such a project, and we’re thrilled by the important work
that this grant will enable.
Google Summer of Code & Season of Docs 2020
https://www.qubes-os.org/news/2020/05/23/google-summer-of-code-and-season-of-docs-2020/
We’re pleased to announce that the Qubes OS Project will be
participating in both Google Summer of Code (https://summerofcode.withgoogle.com/) and Google Season of
Docs (https://developers.google.com/season-of-docs) for 2020!
For Google Summer of Code this year, William Huang will be working on
Template Manager and Package Handling Improvements (https://summerofcode.withgoogle.com/projects/#6190965460566016) under the
mentorship of Qubes project lead Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki).
Specifically, William will be “designing a better mechanism for handling
template installation and creating a user-facing application to deal
with such mechanism and other template-related configuration,
consolidating the management of templates.” For more information about
Google Summer of Code in relation to the Qubes OS project, please see
our information page (https://www.qubes-os.org/gsoc/).
Meanwhile, with Google Season of Docs, we’re still in the technical
writer exploration phase (https://developers.google.com/season-of-docs/docs/timeline), in which “interested technical writers
discuss project ideas with mentoring organizations.” If you’re
interested in participating in Google Season of Docs with Qubes (https://www.qubes-os.org/gsod/),
the technical writer application period begins on June 9, 2020 at 18:00
UTC, and the deadline is July 9, 2020 at 18:00 UTC.
https://www.qubes-os.org/news/2020/05/23/google-summer-of-code-and-season-of-docs-2020/
We’re pleased to announce that the Qubes OS Project will be
participating in both Google Summer of Code (https://summerofcode.withgoogle.com/) and Google Season of
Docs (https://developers.google.com/season-of-docs) for 2020!
For Google Summer of Code this year, William Huang will be working on
Template Manager and Package Handling Improvements (https://summerofcode.withgoogle.com/projects/#6190965460566016) under the
mentorship of Qubes project lead Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki).
Specifically, William will be “designing a better mechanism for handling
template installation and creating a user-facing application to deal
with such mechanism and other template-related configuration,
consolidating the management of templates.” For more information about
Google Summer of Code in relation to the Qubes OS project, please see
our information page (https://www.qubes-os.org/gsoc/).
Meanwhile, with Google Season of Docs, we’re still in the technical
writer exploration phase (https://developers.google.com/season-of-docs/docs/timeline), in which “interested technical writers
discuss project ideas with mentoring organizations.” If you’re
interested in participating in Google Season of Docs with Qubes (https://www.qubes-os.org/gsod/),
the technical writer application period begins on June 9, 2020 at 18:00
UTC, and the deadline is July 9, 2020 at 18:00 UTC.
QSB #057: Special Register Buffer speculative side channel (XSA-320)
https://www.qubes-os.org/news/2020/06/11/qsb-057/
We have just published Qubes Security Bulletin (QSB) #057:
Special Register Buffer speculative side channel (XSA-320).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #057 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-057-2020.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
View XSA-320 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#320
---===[ Qubes Security Bulletin #57 ]===---
2020-06-11
Special Register Buffer speculative side channel (XSA-320)
Summary
========
On 2020-06-09, the Xen Security Team published Xen Security Advisory
320 (CVE-2020-0543 / XSA-320) [1] with the following denoscription:
| This issue is related to the MDS and TAA vulnerabilities. Please see
| https://xenbits.xen.org/xsa/advisory-297.html (MDS) and
| https://xenbits.xen.org/xsa/advisory-305.html (TAA) for details.
|
| Certain processor operations microarchitecturally need to read data
| from outside the physical core (e.g. to communicate with the random
| number generator). In some implementations, this operation is called
| a Special Register Read.
|
| In some implementations, data are staged in a single shared buffer,
| and a full cache line at a time is returned to the core which made the
| Special Register Read. On parts vulnerable to MFBDS or TAA, an
| attacker may be able to access stale data requested by other cores in
| the system.
|
| For more details, see:
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00320.html
|
|
| An attacker, which could include a malicious untrusted user process on
| a trusted guest, or an untrusted guest, can sample the contents of
| certain off-core accesses by other cores in the system.
|
| This can include data whose use may depend on the secrecy of the
| value, such as data from the Random Number Generator (e.g.
| RDRAND/RDSEED instructions).
This is yet another CPU hardware bug related to speculative execution.
Only Intel processors are affected. The RDRAND instruction became
available in Intel processors starting with Ivy Bridge (3rd gen Intel
Core). See Intel's advisory for a full list of affected CPUs. (Short
version: Most mobile/desktop CPUs are affected, while most Atoms and
server Xeons are not.)
Impact
=======
An attacker can obtain data returned by RDRAND/RDSEED instructions on
another core on the system (including another VM). In practice, Linux
does use RDRAND/RDSEED to seed its random number generator
(/dev/urandom, getrandom(2) etc.), but RDRAND/RDSEED is not the only
source of entropy. So, as long as other sources of entropy are not
compromised, the overall security of the random number generator is
still preserved. In Qubes OS, the situation is further improved by
seeding the random number generator at VM startup using a random seed
provided from dom0. This means that using Linux's random number
generator is still safe in Qubes.
Aside from the Linux kernel using RDRAND/RDSEED as one of its entropy
sources, userspace applications can also issue RDRAND/RDSEED
instructions on their own. Such software is also affected by the bug
described here. The specific impact on such software depends on what the
application does with the random data obtained in this manner.
Patching
=========
Intel has provided a microcode update that mitigates the issue. Please
note that Ivy Bridge processors are considered retired by Intel and no
longer receive microcode updates. This means that Ivy Bridge processors
will remain vulnerable to this issue. To mitigate the problem, we are
https://www.qubes-os.org/news/2020/06/11/qsb-057/
We have just published Qubes Security Bulletin (QSB) #057:
Special Register Buffer speculative side channel (XSA-320).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #057 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-057-2020.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
View XSA-320 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#320
---===[ Qubes Security Bulletin #57 ]===---
2020-06-11
Special Register Buffer speculative side channel (XSA-320)
Summary
========
On 2020-06-09, the Xen Security Team published Xen Security Advisory
320 (CVE-2020-0543 / XSA-320) [1] with the following denoscription:
| This issue is related to the MDS and TAA vulnerabilities. Please see
| https://xenbits.xen.org/xsa/advisory-297.html (MDS) and
| https://xenbits.xen.org/xsa/advisory-305.html (TAA) for details.
|
| Certain processor operations microarchitecturally need to read data
| from outside the physical core (e.g. to communicate with the random
| number generator). In some implementations, this operation is called
| a Special Register Read.
|
| In some implementations, data are staged in a single shared buffer,
| and a full cache line at a time is returned to the core which made the
| Special Register Read. On parts vulnerable to MFBDS or TAA, an
| attacker may be able to access stale data requested by other cores in
| the system.
|
| For more details, see:
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00320.html
|
|
| An attacker, which could include a malicious untrusted user process on
| a trusted guest, or an untrusted guest, can sample the contents of
| certain off-core accesses by other cores in the system.
|
| This can include data whose use may depend on the secrecy of the
| value, such as data from the Random Number Generator (e.g.
| RDRAND/RDSEED instructions).
This is yet another CPU hardware bug related to speculative execution.
Only Intel processors are affected. The RDRAND instruction became
available in Intel processors starting with Ivy Bridge (3rd gen Intel
Core). See Intel's advisory for a full list of affected CPUs. (Short
version: Most mobile/desktop CPUs are affected, while most Atoms and
server Xeons are not.)
Impact
=======
An attacker can obtain data returned by RDRAND/RDSEED instructions on
another core on the system (including another VM). In practice, Linux
does use RDRAND/RDSEED to seed its random number generator
(/dev/urandom, getrandom(2) etc.), but RDRAND/RDSEED is not the only
source of entropy. So, as long as other sources of entropy are not
compromised, the overall security of the random number generator is
still preserved. In Qubes OS, the situation is further improved by
seeding the random number generator at VM startup using a random seed
provided from dom0. This means that using Linux's random number
generator is still safe in Qubes.
Aside from the Linux kernel using RDRAND/RDSEED as one of its entropy
sources, userspace applications can also issue RDRAND/RDSEED
instructions on their own. Such software is also affected by the bug
described here. The specific impact on such software depends on what the
application does with the random data obtained in this manner.
Patching
=========
Intel has provided a microcode update that mitigates the issue. Please
note that Ivy Bridge processors are considered retired by Intel and no
longer receive microcode updates. This means that Ivy Bridge processors
will remain vulnerable to this issue. To mitigate the problem, we are
masking out RDRAND availability to VMs on those affected platforms.
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 4.0:
- microcode_ctl 2.1-30.qubes1
- qubes-core-dom0 4.0.51 (needed for Ivy Bridge platforms only)
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
microcode binaries.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-320.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 4.0:
- microcode_ctl 2.1-30.qubes1
- qubes-core-dom0 4.0.51 (needed for Ivy Bridge platforms only)
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
microcode binaries.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-320.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Qubes Architecture Next Steps: The New Qrexec Policy System
https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/
This is the second article in the “What’s new in Qubes 4.1?” series. You
can find the previous one (about GUI Domains)
here (https://www.qubes-os.org/news/2020/03/18/gui-domain/). While the
introduction of GUI domains is a big, singular feature, the changes to
qrexec are more complex and varied — but also very important.
What is qrexec?
You might have been using Qubes for a while and never encountered the
word “qrexec,” but it is one of the crucial components in the system.
Qubes provides isolation and compartmentalization. Separate qubes are
separate worlds, and what the user does in one qube should not impact
another qube. That is, of course, not realistic. In the real world, we
often need and want to do things like copying and pasting, sending
files, routing internet traffic, and simply synchronizing the time. This
is where qrexec comes in: It is an RPC (remote procedure call) mechanism
that allows one qube to do something inside another qube. Of course,
allowing everything all the time would be extremely dangerous. Thus, a
part of qrexec called “qrexec policy” is also used to enforce who can do
what and where. Furthermore, we want to be able to audit what was done,
and this is provided with the logging capabilities of qrexec. The how
is controlled by qrexec services, which are executed by qrexec and also
must be designed in a secure and resilient way. This post focuses mainly
on qrexec itself, but qrexec services will make a brief appearance.
Overview of changes
Most of this post will be very technical. If you don’t care about
writing your own qrexec policies and services, feel free to just read
this overview.
Before we get into nitty-gritty technical details, here’s a brief, less
technical overview of Qubes 4.1 qrexec changes and what they mean for
users and developers:
A new qrexec policy format. (The old format is still supported, but
the new one is very much superior, allowing for easier-to-read
policies, more qube-centered customization, better auditing, and
more.)
Big performance improvements: bigger data chunk sizes for faster
transfers of large amounts of data, qrexec policy daemon for faster
policy evaluation and call setup, resulting in up to seven-fold
faster qrexec service calls.
Support for socket services: better performance for services that can
use a socket-based implementation with significantly faster setup and
connection times.
Policy notifications that make any abnormal behavior easier to detect
and any problems resulting from incorrect permissions easier to
solve.
There is one other big upcoming change (which is not yet fully
implemented and will arrive after Qubes 4.1): We are working on a qrexec
policy API, that is, a set of qrexec services that will allow for
managing qrexec policies without manually editing policy files. It’s
another step toward separating the user from dom0 and protecting the
vulnerable system internals by isolating them from the outside world to
the greatest extent possible.
New policy format
In Qubes 4.0 and earlier, policies were stored as multiple files, one
for each service. While changing permissions for a single action was
easy, managing permissions for an entire qube was very cumbersome. The
new Qubes 4.1 policy format completely overhauls this approach and
introduces several convenience features to make policy management easier
and more secure.
What if you’ve already spent time carefully crafting your policies in
Qubes 4.0? Don’t worry. The old policy format will still be supported
until at least Qubes 5.0.
You can find details of the development of the new policy format
here (https://github.com/QubesOS/qubes-issues/issues/4370).
Policy files
The biggest difference between the old and new policy formats is that,
under the new format, the entire policy is a single entity. It is not
https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/
This is the second article in the “What’s new in Qubes 4.1?” series. You
can find the previous one (about GUI Domains)
here (https://www.qubes-os.org/news/2020/03/18/gui-domain/). While the
introduction of GUI domains is a big, singular feature, the changes to
qrexec are more complex and varied — but also very important.
What is qrexec?
You might have been using Qubes for a while and never encountered the
word “qrexec,” but it is one of the crucial components in the system.
Qubes provides isolation and compartmentalization. Separate qubes are
separate worlds, and what the user does in one qube should not impact
another qube. That is, of course, not realistic. In the real world, we
often need and want to do things like copying and pasting, sending
files, routing internet traffic, and simply synchronizing the time. This
is where qrexec comes in: It is an RPC (remote procedure call) mechanism
that allows one qube to do something inside another qube. Of course,
allowing everything all the time would be extremely dangerous. Thus, a
part of qrexec called “qrexec policy” is also used to enforce who can do
what and where. Furthermore, we want to be able to audit what was done,
and this is provided with the logging capabilities of qrexec. The how
is controlled by qrexec services, which are executed by qrexec and also
must be designed in a secure and resilient way. This post focuses mainly
on qrexec itself, but qrexec services will make a brief appearance.
Overview of changes
Most of this post will be very technical. If you don’t care about
writing your own qrexec policies and services, feel free to just read
this overview.
Before we get into nitty-gritty technical details, here’s a brief, less
technical overview of Qubes 4.1 qrexec changes and what they mean for
users and developers:
A new qrexec policy format. (The old format is still supported, but
the new one is very much superior, allowing for easier-to-read
policies, more qube-centered customization, better auditing, and
more.)
Big performance improvements: bigger data chunk sizes for faster
transfers of large amounts of data, qrexec policy daemon for faster
policy evaluation and call setup, resulting in up to seven-fold
faster qrexec service calls.
Support for socket services: better performance for services that can
use a socket-based implementation with significantly faster setup and
connection times.
Policy notifications that make any abnormal behavior easier to detect
and any problems resulting from incorrect permissions easier to
solve.
There is one other big upcoming change (which is not yet fully
implemented and will arrive after Qubes 4.1): We are working on a qrexec
policy API, that is, a set of qrexec services that will allow for
managing qrexec policies without manually editing policy files. It’s
another step toward separating the user from dom0 and protecting the
vulnerable system internals by isolating them from the outside world to
the greatest extent possible.
New policy format
In Qubes 4.0 and earlier, policies were stored as multiple files, one
for each service. While changing permissions for a single action was
easy, managing permissions for an entire qube was very cumbersome. The
new Qubes 4.1 policy format completely overhauls this approach and
introduces several convenience features to make policy management easier
and more secure.
What if you’ve already spent time carefully crafting your policies in
Qubes 4.0? Don’t worry. The old policy format will still be supported
until at least Qubes 5.0.
You can find details of the development of the new policy format
here (https://github.com/QubesOS/qubes-issues/issues/4370).
Policy files
The biggest difference between the old and new policy formats is that,
under the new format, the entire policy is a single entity. It is not
divided into separate, per-service fragments. While it can be stored in
multiple files located in multiple places, the files are equivalent, and
each can describe policies for multiple services. In other words, we are
moving from a set of tables to one big, flat table.
The policy files, stored previously in /etc/qubes-rpc/policy/, are now
located in /etc/qubes/policy.d/. Furthermore, each file must have a
.policy extension, and any temporary files will no longer cause
issues. Under the old format, there were dozens files:
/etc/qubes-rpc/policy/
├── admin.backup.Cancel
├── admin.backup.Execute
├── admin.backup.Info
├── include
│ ├── admin-local-ro
│ ├── admin-local-rwx
│ ├── admin-global-ro
│ ├── admin-global-rwx
├── …
├── qubes.Gpg
├── qubes.StartApp
├── …
├── whonix.SdwdateStatus
Under the new format, we simply have:
/etc/qubes/policy.d/
├── 35-compat.policy
├── 90-admin-default.policy
├── 90-default.policy
├── include
│ ├── admin-local-ro
│ ├── admin-local-rwx
│ ├── admin-global-ro
│ ├── admin-global-rwx
(and any additional user-defined files)
Here’s an example of an old policy file (qubes.GetDate.policy):
## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect
## Please use a single # to start your custom comments
$tag:anon-vm $anyvm deny
$anyvm $anyvm allow,target=dom0
Here’s an example of the beginning of a new policy file
(90-default.policy):
## Do not modify this file, create a new policy file with lower number in the
## filename instead. For example `30-user.policy`.
###
### Default qrexec policy
###
## File format:
## service-name|* +argument|* source destination action [options]
## Note that policy parsing stops at the first match.
# policy.RegisterArgument should be allowed only for specific arguments.
policy.RegisterArgument * @anyvm dom0 deny
# WARNING: The qubes.ConnectTCP service is dangerous and allows any
# qube to access any other qube TCP port. It should be restricted
# only to restricted qubes. This is why the default policy is 'deny'
# Example of policy: qubes.ConnectTCP +22 mytcp-client @default allow,target=mytcp-server
qubes.ConnectTCP * @anyvm @anyvm deny
# VM advertise its supported features
qubes.FeaturesRequest * @anyvm dom0 allow
# Windows VM advertise installed Qubes Windows Tools
qubes.NotifyTools * @anyvm dom0 allow
# File copy/move
qubes.Filecopy * @anyvm @anyvm ask
# Get current date/time
qubes.GetDate * @tag:anon-vm @anyvm deny
qubes.GetDate * @anyvm @anyvm allow target=dom0
Under the new format, the policy for a single qube is much easier to
find, parse, and edit. It’s all contained in a single file, and by using
wildcards (see below), it’s much easier to read and understand. For
example, it’s trivial now to forbid all calls for a given qube or forbid
all with a list of exceptions. This allows for a more qube-centric
approach to policies, and while the results are theoretically the same,
there’s a huge difference between a couple of rules, all in one places,
and dozens of rules spread across dozens of files. It’s especially
important for Admin API policies. (The Admin API provides qrexec calls
for querying system state. There are a lot of them, and they are needed
by system qubes such as GUI domains. Under the old policy format, it was
quite arduous to edit them when each call had its own policy file.)
Now that the policy is a single entity, it is parsed as a whole. If
there are any syntax errors, the parser will refuse to load anything (in
order to prevent any unintended permission grants). The system is
designed to “failed closed”: An empty policy results in all qrexec calls
being denied. While this protects users from their own mistakes, users
multiple files located in multiple places, the files are equivalent, and
each can describe policies for multiple services. In other words, we are
moving from a set of tables to one big, flat table.
The policy files, stored previously in /etc/qubes-rpc/policy/, are now
located in /etc/qubes/policy.d/. Furthermore, each file must have a
.policy extension, and any temporary files will no longer cause
issues. Under the old format, there were dozens files:
/etc/qubes-rpc/policy/
├── admin.backup.Cancel
├── admin.backup.Execute
├── admin.backup.Info
├── include
│ ├── admin-local-ro
│ ├── admin-local-rwx
│ ├── admin-global-ro
│ ├── admin-global-rwx
├── …
├── qubes.Gpg
├── qubes.StartApp
├── …
├── whonix.SdwdateStatus
Under the new format, we simply have:
/etc/qubes/policy.d/
├── 35-compat.policy
├── 90-admin-default.policy
├── 90-default.policy
├── include
│ ├── admin-local-ro
│ ├── admin-local-rwx
│ ├── admin-global-ro
│ ├── admin-global-rwx
(and any additional user-defined files)
Here’s an example of an old policy file (qubes.GetDate.policy):
## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect
## Please use a single # to start your custom comments
$tag:anon-vm $anyvm deny
$anyvm $anyvm allow,target=dom0
Here’s an example of the beginning of a new policy file
(90-default.policy):
## Do not modify this file, create a new policy file with lower number in the
## filename instead. For example `30-user.policy`.
###
### Default qrexec policy
###
## File format:
## service-name|* +argument|* source destination action [options]
## Note that policy parsing stops at the first match.
# policy.RegisterArgument should be allowed only for specific arguments.
policy.RegisterArgument * @anyvm dom0 deny
# WARNING: The qubes.ConnectTCP service is dangerous and allows any
# qube to access any other qube TCP port. It should be restricted
# only to restricted qubes. This is why the default policy is 'deny'
# Example of policy: qubes.ConnectTCP +22 mytcp-client @default allow,target=mytcp-server
qubes.ConnectTCP * @anyvm @anyvm deny
# VM advertise its supported features
qubes.FeaturesRequest * @anyvm dom0 allow
# Windows VM advertise installed Qubes Windows Tools
qubes.NotifyTools * @anyvm dom0 allow
# File copy/move
qubes.Filecopy * @anyvm @anyvm ask
# Get current date/time
qubes.GetDate * @tag:anon-vm @anyvm deny
qubes.GetDate * @anyvm @anyvm allow target=dom0
Under the new format, the policy for a single qube is much easier to
find, parse, and edit. It’s all contained in a single file, and by using
wildcards (see below), it’s much easier to read and understand. For
example, it’s trivial now to forbid all calls for a given qube or forbid
all with a list of exceptions. This allows for a more qube-centric
approach to policies, and while the results are theoretically the same,
there’s a huge difference between a couple of rules, all in one places,
and dozens of rules spread across dozens of files. It’s especially
important for Admin API policies. (The Admin API provides qrexec calls
for querying system state. There are a lot of them, and they are needed
by system qubes such as GUI domains. Under the old policy format, it was
quite arduous to edit them when each call had its own policy file.)
Now that the policy is a single entity, it is parsed as a whole. If
there are any syntax errors, the parser will refuse to load anything (in
order to prevent any unintended permission grants). The system is
designed to “failed closed”: An empty policy results in all qrexec calls
being denied. While this protects users from their own mistakes, users
should still be careful when editing policies so that the system remains
functional. This is similar to the approach that tools such as sudo
take, and we decided that it makes for a safer system on the whole. In
the future, Qubes will also include a Policy API (see below) that will
include calls for modifying the policy in a safe way that prevents
syntax errors.
New column syntax
The full specification can be found
here (https://github.com/QubesOS/qubes-core-qrexec/blob/master/Documentation/multifile-policy.markdown).
Old policy files had three columns: source qube, target qube, and action
(allow/deny/ask with optional arguments). Because the new policy format
no longer includes the service name in the file name, we had to change
this a bit to a five-column format: service name, service argument,
source qube, target qube, and action.
qrexec.Service +ARGUMENT SRCQUBE DSTQUBE {allow|deny|ask} [PARAM=VALUE [PARAM=VALUE ...]]
Under the old format, you could use wildcards only in the source qube
and target qube fields. Under the new format, you can also use wildcards
in the service name and argument fields. For example, to forbid all
calls from the work qube to the personal qube, you could use this
line:
* * work personal deny
You could also deny all calls from work except for calls to dom0:
* * work dom0 allow
* * work * deny
This, along with the new file structure, results in much clearer,
qube-centered policy rules.
A minor change is the replacement of commas with spaces in the parameter
list. For example, a ConnectTCP policy could look like this:
qubes.ConnectTCP * mytcp-client @default allow target=mytcp-server
Security in symbols
The old policy format used the $ character in multiple keywords, such
as $default and $dispvm. Due to a potential issue described in
Qubes Security Bulletin #38 (https://www.qubes-os.org/news/2018/02/20/qsb-38/),
we have been getting rid of $. (In brief, interaction between Bash
shell parameter expansion and $ characters in policy files could
theoretically lead to security problems.) For backward compatibility,
$ is still supported in policy files, but it is being internally
turned into @ before processing, and in the new policy format, we only
use @. In other words, $default in Qubes 4.0 will now be @default,
$dispvm turns into @dispvm, and so on. For example, to update all
TemplateVMs through sys-whonix, you would use:
qubes.UpdatesProxy * @type:TemplateVM @default allow target=sys-whonix
In all client tools, $ will still be automatically translated into
@, so you don’t have to change any existing noscripts. However, we
highly recommend using only @. Legacy support for $ will continue
throughout the Qubes 4.x series and end in Qubes 5.0.
Includes
The old format supported a simple $include directive. In Qubes 4.1,
the inclusion capabilities are extended, and we now have four different
kinds of includes. Due to the aforementioned QSB #38 change, the
keywords no longer start with $, but rather with an exclamation point
(!). The supported include directives are:
!include path_to_file — The simplest command. Includes the entire
contents of the file and parses it according to new policy syntax
rules. The file can contain policy rules for one or more services,
for one or more qubes.
!include-dir path_to_directory — Includes all .policy files
from the directory, parsing them according to new policy syntax
rules.
!include-service service argument path_to_file — Allows for the
inclusion of a policy in a format similar to the old one (without a
service or an argument) by filling in the missing service and
argument fields from the new format with parameters provided to
include-service. Either of those (or both) can be a wildcard (*),
as they can be in all new policy files. (This might seem like a
directive useful only for backward compatibility, but it also has
uses in the Admin API policies used for implementing GUI domains,
among other things.)
functional. This is similar to the approach that tools such as sudo
take, and we decided that it makes for a safer system on the whole. In
the future, Qubes will also include a Policy API (see below) that will
include calls for modifying the policy in a safe way that prevents
syntax errors.
New column syntax
The full specification can be found
here (https://github.com/QubesOS/qubes-core-qrexec/blob/master/Documentation/multifile-policy.markdown).
Old policy files had three columns: source qube, target qube, and action
(allow/deny/ask with optional arguments). Because the new policy format
no longer includes the service name in the file name, we had to change
this a bit to a five-column format: service name, service argument,
source qube, target qube, and action.
qrexec.Service +ARGUMENT SRCQUBE DSTQUBE {allow|deny|ask} [PARAM=VALUE [PARAM=VALUE ...]]
Under the old format, you could use wildcards only in the source qube
and target qube fields. Under the new format, you can also use wildcards
in the service name and argument fields. For example, to forbid all
calls from the work qube to the personal qube, you could use this
line:
* * work personal deny
You could also deny all calls from work except for calls to dom0:
* * work dom0 allow
* * work * deny
This, along with the new file structure, results in much clearer,
qube-centered policy rules.
A minor change is the replacement of commas with spaces in the parameter
list. For example, a ConnectTCP policy could look like this:
qubes.ConnectTCP * mytcp-client @default allow target=mytcp-server
Security in symbols
The old policy format used the $ character in multiple keywords, such
as $default and $dispvm. Due to a potential issue described in
Qubes Security Bulletin #38 (https://www.qubes-os.org/news/2018/02/20/qsb-38/),
we have been getting rid of $. (In brief, interaction between Bash
shell parameter expansion and $ characters in policy files could
theoretically lead to security problems.) For backward compatibility,
$ is still supported in policy files, but it is being internally
turned into @ before processing, and in the new policy format, we only
use @. In other words, $default in Qubes 4.0 will now be @default,
$dispvm turns into @dispvm, and so on. For example, to update all
TemplateVMs through sys-whonix, you would use:
qubes.UpdatesProxy * @type:TemplateVM @default allow target=sys-whonix
In all client tools, $ will still be automatically translated into
@, so you don’t have to change any existing noscripts. However, we
highly recommend using only @. Legacy support for $ will continue
throughout the Qubes 4.x series and end in Qubes 5.0.
Includes
The old format supported a simple $include directive. In Qubes 4.1,
the inclusion capabilities are extended, and we now have four different
kinds of includes. Due to the aforementioned QSB #38 change, the
keywords no longer start with $, but rather with an exclamation point
(!). The supported include directives are:
!include path_to_file — The simplest command. Includes the entire
contents of the file and parses it according to new policy syntax
rules. The file can contain policy rules for one or more services,
for one or more qubes.
!include-dir path_to_directory — Includes all .policy files
from the directory, parsing them according to new policy syntax
rules.
!include-service service argument path_to_file — Allows for the
inclusion of a policy in a format similar to the old one (without a
service or an argument) by filling in the missing service and
argument fields from the new format with parameters provided to
include-service. Either of those (or both) can be a wildcard (*),
as they can be in all new policy files. (This might seem like a
directive useful only for backward compatibility, but it also has
uses in the Admin API policies used for implementing GUI domains,
among other things.)
!compat-4.0 — An explicit backward compatibility directive that
takes the old policy files from their old locations and converts them
internally (using include-service) to be a part of the new policy.
Backward compatibility
One of the new policy files is 35-compat.policy. It loads the old
policy files and parses them in a way compatible with the new policy
format.
Before the old policy format is completely phased out in Qubes 5.0, we
will provide a conversion tool. (This tool may not be available in Qubes
4.1 on release.) Since there will be legacy support for the old policy
format with 35-compat.policy and the !compat-4.0 include directive,
it is not necessary for users to update their current custom policies
for Qubes 4.1.
Performance improvements
In Qubes 4.1, the max qrexec data chunk size has been increased from 4kB
to 64kB. This makes large data transfers significantly faster, for
example, copying big files or streaming video through qvm-usb from
sys-usb to a qube with an ongoing video call. (Details can be found
here (https://github.com/QubesOS/qubes-issues/issues/4909).)
We have also significantly increased the maximum service and argument
length. In Qubes 4.0, it was just 63 characters for the combined
service+arguments. Now, it is 65,000 characters (a bit less than 64kB,
due to an internal header). The main reason for this change — apart
from sheer convenience — is the qubes.VMShell service. It’s an
extremely dangerous service that gives complete shell access.
Unsurprisingly, it’s not allowed by default. In Qubes 4.0,
qubes.VMShell just provides a shell stdin/stdout, so handling it with
a single command was extremely cumbersome and often required a
prodigious number of quotation marks. Even worse, the command was not
stored in any log file, and qrexec policy did not control what commands
could be executed, opening up a big, unauditable, dangerous space for
exploitation. By increasing the service+argument length (and governing
the argument under qrexec policy, as described above), we are able to
introduce a new, more accountable, safer service. In Qubes 4.1, this new
service is called qubes.VMExec, and the complete command to be
executed, along with its arguments, is logged. This allows for precise
control, as the policy can allow only certain commands, not everything
that can be executed in a shell. Moreover, all the arguments are
explicitly defined and unambiguous, freeing the user from quotation mark
purgatory. (The syntax is described
here (https://www.qubes-os.org/doc/vm-interface/#qubes-rpc).) Other
services will also benefit, such as the U2F implementation that, due to
previous limitations, required some awkward wrangling of the public key
hash. (Details can be found
here (https://github.com/QubesOS/qubes-issues/issues/4850).)
There are also some minor improvements and streamlining coming up: for
example, a new call that allows access to all qube properties at once,
which allows qvm-ls (and similar tools) to work significantly faster.
Instead of making around five Admin API calls per qube, qvm-ls will
now only make one, leading to a five-fold speed increase.
Policy daemon
In Qubes 4.0, performing a qrexec call (with all its assorted policy
checking) was a fairly slow process. Even in the best case (simple
allow, no asking user for input), it consisted of several processes:
loading the whole policy again, loading Python modules required to parse
it, executing the call itself…. The setup alone took about 300 ms (for
a typical system). In the case of a lone operation, such as copying a
file, it’s hardly a problem, but for frequent operations it could be a
disaster. Tunneling a TCP connection via qrexec (the qubes.ConnectTCP
service) would mean a 300 ms lag for establishing the connection — a
complete nightmare for the server! Qubes Clipboard, which also uses
qrexec and is managed by a policy (which allows for blocking copy or
paste for certain qubes), needed 300 ms for each operation, which can be
takes the old policy files from their old locations and converts them
internally (using include-service) to be a part of the new policy.
Backward compatibility
One of the new policy files is 35-compat.policy. It loads the old
policy files and parses them in a way compatible with the new policy
format.
Before the old policy format is completely phased out in Qubes 5.0, we
will provide a conversion tool. (This tool may not be available in Qubes
4.1 on release.) Since there will be legacy support for the old policy
format with 35-compat.policy and the !compat-4.0 include directive,
it is not necessary for users to update their current custom policies
for Qubes 4.1.
Performance improvements
In Qubes 4.1, the max qrexec data chunk size has been increased from 4kB
to 64kB. This makes large data transfers significantly faster, for
example, copying big files or streaming video through qvm-usb from
sys-usb to a qube with an ongoing video call. (Details can be found
here (https://github.com/QubesOS/qubes-issues/issues/4909).)
We have also significantly increased the maximum service and argument
length. In Qubes 4.0, it was just 63 characters for the combined
service+arguments. Now, it is 65,000 characters (a bit less than 64kB,
due to an internal header). The main reason for this change — apart
from sheer convenience — is the qubes.VMShell service. It’s an
extremely dangerous service that gives complete shell access.
Unsurprisingly, it’s not allowed by default. In Qubes 4.0,
qubes.VMShell just provides a shell stdin/stdout, so handling it with
a single command was extremely cumbersome and often required a
prodigious number of quotation marks. Even worse, the command was not
stored in any log file, and qrexec policy did not control what commands
could be executed, opening up a big, unauditable, dangerous space for
exploitation. By increasing the service+argument length (and governing
the argument under qrexec policy, as described above), we are able to
introduce a new, more accountable, safer service. In Qubes 4.1, this new
service is called qubes.VMExec, and the complete command to be
executed, along with its arguments, is logged. This allows for precise
control, as the policy can allow only certain commands, not everything
that can be executed in a shell. Moreover, all the arguments are
explicitly defined and unambiguous, freeing the user from quotation mark
purgatory. (The syntax is described
here (https://www.qubes-os.org/doc/vm-interface/#qubes-rpc).) Other
services will also benefit, such as the U2F implementation that, due to
previous limitations, required some awkward wrangling of the public key
hash. (Details can be found
here (https://github.com/QubesOS/qubes-issues/issues/4850).)
There are also some minor improvements and streamlining coming up: for
example, a new call that allows access to all qube properties at once,
which allows qvm-ls (and similar tools) to work significantly faster.
Instead of making around five Admin API calls per qube, qvm-ls will
now only make one, leading to a five-fold speed increase.
Policy daemon
In Qubes 4.0, performing a qrexec call (with all its assorted policy
checking) was a fairly slow process. Even in the best case (simple
allow, no asking user for input), it consisted of several processes:
loading the whole policy again, loading Python modules required to parse
it, executing the call itself…. The setup alone took about 300 ms (for
a typical system). In the case of a lone operation, such as copying a
file, it’s hardly a problem, but for frequent operations it could be a
disaster. Tunneling a TCP connection via qrexec (the qubes.ConnectTCP
service) would mean a 300 ms lag for establishing the connection — a
complete nightmare for the server! Qubes Clipboard, which also uses
qrexec and is managed by a policy (which allows for blocking copy or
paste for certain qubes), needed 300 ms for each operation, which can be
a bit of a problem for particularly fast typists. The biggest problem
was, however, the Admin API. The whole idea of an Admin API (read more
here (https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/))
requires a lot of qrexec calls. If we want to implement a GUI domain
that manages certain parts of the system instead of having the user
directly access dom0, we need the Admin API to be much, much faster. For
example, without the changes outlined below, starting the Qube Manager
on a default, out-of-the-box Qubes installation with a GUI domain took
37 seconds. This is just unacceptable.
To speed up qrexec calls, Qubes 4.1 introduces a policy daemon. It is a
process that loads the policy into memory and keeps it there (only
reloading when the policy files change), answering qrexec queries about
whether a given operation should be accepted or denied without spawning
new processes or loading more files and Python modules. The results are
quite satisfying. Starting the Qube Manager in a default Qubes
installation with a GUI domain takes less than 5 seconds — a more than
seven-fold improvement.
Socket services
Another problematic bottleneck for qrexec was that each service was a
new process. In many cases, this process just connects to an existing
service. A particularly egregious example is the Admin API. An Admin API
call is just a connection to dom0’s qubesd daemon, but in Qubes 4.0 each
of its calls was a separate process, going through a bunch of shell
noscripts to return a simple chunk of data. For a program like qvm-ls,
which has to access a lot of data from the Admin API, it was a
performance nightmare.
A qrexec service is a file residing in /etc/qubes-rpc/. In Qubes 4.0,
it has to be an executable or a symlink to one. In Qubes 4.1, however,
it can also be a symlink to a unix socket. Via this socket, you can
simply connect to an existing process that will handle your call. With
each socket connection, this running service receives a new connection
with a metadata header (containing information on who wants to do what
and where, a service name just in case, and a terminating 0 byte)
followed by the same client data as before. Thus, even though it’s a
single process that handles multiple calls, it knows where each call
came from and what it asked for.
Performance gains on both speed and memory benchmarks are significant.
For example, we have an icon rendering service, which is responsible for
making sure each of your program icons bears the color of its qube. In
Qubes 4.0, each invocation of this service was a separate per-qube
processes in dom0, each one loading Gtk and other libraries for about
32MB of RAM. In Qubes 4.1, this has been converted into a
single-process, socket-based service. Now, ten running qubes need only
this one socket-based service process, for a single instance of 32MB RAM
usage, instead of ten times that in Qubes 4.0. The Admin API also uses a
socket service, which — combined with the policy daemon described
above — dropped call execution time from 300 ms to about 50 ms.
More information about socket services can be found
here (https://github.com/QubesOS/qubes-issues/issues/3912).
Notifications
Creating a qrexec policy daemon opened another convenient opportunity:
adding notifications for some policy actions. By default, notifications
are shown only when a deny occurs, unless it was due to an ask
action. (If the user was already asked for consent, it is not necessary
to show the notification.) However, the new policy format allows for an
optional notify=no parameter with deny rules. Allow rules support
a notify=yes parameter that will show a notification on accepted
qrexec calls.
was, however, the Admin API. The whole idea of an Admin API (read more
here (https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/))
requires a lot of qrexec calls. If we want to implement a GUI domain
that manages certain parts of the system instead of having the user
directly access dom0, we need the Admin API to be much, much faster. For
example, without the changes outlined below, starting the Qube Manager
on a default, out-of-the-box Qubes installation with a GUI domain took
37 seconds. This is just unacceptable.
To speed up qrexec calls, Qubes 4.1 introduces a policy daemon. It is a
process that loads the policy into memory and keeps it there (only
reloading when the policy files change), answering qrexec queries about
whether a given operation should be accepted or denied without spawning
new processes or loading more files and Python modules. The results are
quite satisfying. Starting the Qube Manager in a default Qubes
installation with a GUI domain takes less than 5 seconds — a more than
seven-fold improvement.
Socket services
Another problematic bottleneck for qrexec was that each service was a
new process. In many cases, this process just connects to an existing
service. A particularly egregious example is the Admin API. An Admin API
call is just a connection to dom0’s qubesd daemon, but in Qubes 4.0 each
of its calls was a separate process, going through a bunch of shell
noscripts to return a simple chunk of data. For a program like qvm-ls,
which has to access a lot of data from the Admin API, it was a
performance nightmare.
A qrexec service is a file residing in /etc/qubes-rpc/. In Qubes 4.0,
it has to be an executable or a symlink to one. In Qubes 4.1, however,
it can also be a symlink to a unix socket. Via this socket, you can
simply connect to an existing process that will handle your call. With
each socket connection, this running service receives a new connection
with a metadata header (containing information on who wants to do what
and where, a service name just in case, and a terminating 0 byte)
followed by the same client data as before. Thus, even though it’s a
single process that handles multiple calls, it knows where each call
came from and what it asked for.
Performance gains on both speed and memory benchmarks are significant.
For example, we have an icon rendering service, which is responsible for
making sure each of your program icons bears the color of its qube. In
Qubes 4.0, each invocation of this service was a separate per-qube
processes in dom0, each one loading Gtk and other libraries for about
32MB of RAM. In Qubes 4.1, this has been converted into a
single-process, socket-based service. Now, ten running qubes need only
this one socket-based service process, for a single instance of 32MB RAM
usage, instead of ten times that in Qubes 4.0. The Admin API also uses a
socket service, which — combined with the policy daemon described
above — dropped call execution time from 300 ms to about 50 ms.
More information about socket services can be found
here (https://github.com/QubesOS/qubes-issues/issues/3912).
Notifications
Creating a qrexec policy daemon opened another convenient opportunity:
adding notifications for some policy actions. By default, notifications
are shown only when a deny occurs, unless it was due to an ask
action. (If the user was already asked for consent, it is not necessary
to show the notification.) However, the new policy format allows for an
optional notify=no parameter with deny rules. Allow rules support
a notify=yes parameter that will show a notification on accepted
qrexec calls.