For example, this rule will cause notifications to be shown whenever a
qubes.VMExec service call is made from the work qube to the
personal qube:

qubes.VMExec * work personal allow notify=yes


And the above screenshot could be accomplished with:

qubes.Gpg * work work-gpg allow notify=yes
qubes.Filecopy * untrusted * deny


Notifications alert the user that something unexpected might have
happened. They can signal a misconfigured policy (when calls are denied
while the user would prefer them to be allowed) or a misbehaving or
malicious qube (when unexpected calls are being made and denied due to a
correctly configured policy).

The introduction of GUI domains makes the subject of qrexec
notifications a bit more complex. Since there can be more than one GUI
domain, which one should receive notifications? For now, we’ve decided
that the GUI domain serving the source qube (the one making the call)
will show notifications. There are some conceivable setups in which a
different GUI domain would show notifications. While such setups will
not be supported in Qubes 4.1, they may appear in future versions.

More information about notifications can be found
here (https://github.com/QubesOS/qubes-issues/issues/3904).

Policy API (in development)

As we mentioned above, one of our big development goals is separating
the user from the most vulnerable part of the system: dom0. Doing so
improves compartmentalization and security while lowering both the
attack surface and the chance of accidentally committing a compromising
mistake.

In order to completely isolate dom0, however, we would have to provide
qrexec interfaces for everything that the user may need to access and
configure — including the qrexec policy itself. At the moment, we are
working on a broad Policy API that allows for editing the whole policy.
The Policy API will also enforce the correctness of any policy changes,
preventing users from making syntactically invalid policy changes.

We also have some ideas for implementing limited access, for example,
having a deprivileged user who is limited to modifying certain services
or controlling access to certain qubes. The design for this is not yet
final. In its current state, we are thinking about supporting two kinds
of roles: an API administrator with total access, and an operator with
access to only a well-defined subset of the policy. The implementation
of any such ideas will definitely not be a part of Qubes 4.1.

Current work on the Policy API design draft and a proof of concept can
be found here (https://github.com/QubesOS/qubes-policy-control).

Fedora 32 TemplateVMs available
https://www.qubes-os.org/news/2020/06/30/fedora-32-templates-available/

New Fedora 32 TemplateVMs are now available for both Qubes 4.0 and 4.1.

Important: If you wish to use the Qubes Update widget to update a
Fedora 32 template, you must first switch (https://www.qubes-os.org/doc/templates/#switching) the
default-mgmt-dvm qube to a Fedora 32 template. (Alternatively, you
can create a separate management DisposableVM Template based on a
Fedora 32 template for the purpose of updating Fedora 32 templates.)
This does not affect updating internally using dnf.

Instructions are available for upgrading Fedora TemplateVMs (https://www.qubes-os.org/doc/template/fedora/upgrade/). We also
provide fresh Fedora 32 TemplateVM packages 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 32 TemplateVM:

$ sudo qubes-dom0-update qubes-template-fedora-32


Minimal (https://www.qubes-os.org/doc/templates/minimal/) Fedora 32 TemplateVM:

$ sudo qubes-dom0-update qubes-template-fedora-32-minimal


After installing or upgrading a TemplateVM, please remember to update (https://www.qubes-os.org/doc/software-update-domu/)
(see important note above) and switch all qubes that were using the
old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).

QSB #058: Insufficient cache write-back under VT-d (XSA-321)
https://www.qubes-os.org/news/2020/07/07/qsb-058/

We have just published Qubes Security Bulletin (QSB) #058:
Insufficient cache write-back under VT-d (XSA-321).
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 #058 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-058-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-321 in the XSA Tracker:

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



---===[ Qubes Security Bulletin #58 ]===---

2020-07-07


Insufficient cache write-back under VT-d (XSA-321)


Summary
========

On 2020-07-07, the Xen Security Team published Xen Security Advisory
321 (CVE-2020-15565 / XSA-321) [1] with the following denoscription:

| When page tables are shared between IOMMU and CPU, changes to them
| require flushing of both TLBs. Furthermore, IOMMUs may be non-coherent,
| and hence prior to flushing IOMMU TLBs CPU cached also needs writing
| back to memory after changes were made. Such writing back of cached
| data was missing in particular when splitting large page mappings into
| smaller granularity ones.
|
| A malicious guest may be able to retain read/write DMA access to
| frames returned to Xen's free pool, and later reused for another
| purpose. Host crashes (leading to a Denial of Service) and privilege
| escalation cannot be ruled out.

A malicious HVM qube with a PCI device (such as sys-net or sys-usb in
Qubes' default configuration) can potentially compromise the whole
system.

Only Intel systems are affected. AMD systems are not affected.


Patching
=========

The specific packages that resolve the problems discussed in this
bulletin are as follows:

For Qubes 4.0:
- Xen packages, version 4.8.5-19

The packages are to be installed in dom0 via the Qube 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
Xen binaries.


Credits
========

See the original Xen Security Advisory.


References
===========

[1] https://xenbits.xen.org/xsa/advisory-321.html

--
The Qubes Security Team
https://www.qubes-os.org/security/

XSAs 317, 319, 327, and 328 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2020/07/07/xsa-317-319-327-328-qubes-not-affected/

The Xen Project has published Xen Security Advisories 317, 319, 327, and
328 (XSA-317, XSA-319, XSA-327, and XSA-328, 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/#317
https://www.qubes-os.org/security/xsa/#319
https://www.qubes-os.org/security/xsa/#327
https://www.qubes-os.org/security/xsa/#328

XSA-329 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2020/07/16/xsa-329-qubes-not-affected/

The Xen Project has published Xen Security Advisory 329 (XSA-329). 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/#329

Xen Project Hypervisor Version 4.14 brings added security and performance
https://xenproject.org/2020/07/24/xen-project-hypervisor-version-4-14-brings-added-security-and-performance/

New version introduces Linux stubdomains and robust live patching to build on security features. SAN FRANCISCO – July 24, 2020 — The Xen Project, an open source hypervisor hosted at...

HVMI becomes A Xen Project Incubating Project
https://xenproject.org/2020/07/30/hvmi-becomes-a-xen-project-incubating-project/

Today, the Xen Project is thrilled to welcome Hypervisor-based Memory Introspection (HVMI) as an incubating project!  Contributed by Bitdefender, a leading global cybersecurity company protecting over 500 million systems worldwide...

New community forum for Qubes OS users!
https://www.qubes-os.org/news/2020/08/20/new-community-forum-for-qubes-os-users/

We’re pleased to announce the launch of a new forum for Qubes OS users:
https://qubes-os.discourse.group (https://qubes-os.discourse.group/)

This is an official user forum where you can ask questions, get help,
share tips and experiences, and more! For a long time, members of our
community have sought a privacy-respecting forum experience with modern
features that traditional mailing lists do not support. The open-source
Discourse (https://www.discourse.org/) platform fills this need for us, as it does for many other
open-source projects. Thanks to their generous free hosting for open
source projects (https://blog.discourse.org/2018/11/free-hosting-for-open-source-v2/), we’re pleased to be able to create this space for our
community.

Why create a forum now?

Previously, the only option for a forum-like experience was to interact
with our mailing lists via Google Groups, but we understand all too well
that the privacy implications and user experience were unacceptable for
many members of our community, especially with the recent addition of a
sign-in requirement to view threads. Many of you value the lower barrier
to entry, organization, ease-of-use, and modern social features that
today’s forums support. Moreover, Discourse features email integration
for those who still prefer the traditional mailing list format.

How is this different from our mailing lists?

To be clear, this is not a replacement for our mailing lists (https://www.qubes-os.org/support/#mailing-lists) (such
as qubes-users and qubes-devel), which will continue on as they are.
This new forum is simply an additional place for discussion. Certain
types of discussions naturally lend themselves more to mailing lists or
to forums, and different types of users prefer different venues. We’ve
heard from some users who find the mailing lists to be a bit
intimidating or who may feel that their message isn’t important enough
to merit creating a new email that lands in thousands of inboxes. Others
want more selective control over topic notifications. Some users simply
appreciate the ability to add a “reaction” to a message instead of
having to add an entirely new reply. Whatever your reasons, it’s up to
you to decide where and how you want to join the conversation.

Will this split the community?

Many open-source projects (such as Fedora and Debian) have both mailing
lists and forums (and additional discussion venues). In fact, Qubes
already has non-mailing-list discussion venues such as IRC (https://www.qubes-os.org/support/#unofficial-chat-channels) and
Reddit (https://www.reddit.com/r/Qubes/). We believe that this additional venue will foster the
continued growth of community participation and improve everyone’s
experience. In addition, we fully expect that many community members –
especially the most active ones – will choose to participate in both
venues. (Again, for those who still prefer interacting via email,
Discourse supports that too!)

Special thanks to Michael Carbone for spearheading the creation of this
forum and to deeplow who, as our first forum administrator, has done
much of the legwork to help get it looking good and working well!

On the other hand, there's also an unofficial support group where you can ask questions and get help right here on Telegram!

If you're interested, join our private group by tapping on "Discuss" and then tap "Join".

If you want to share the group, you can do so using this link: https://news.1rj.ru/str/joinchat/B8FHpkEToMfgdREGV7wzRQ

LET'S KEEP THE COMMUNITY GROWING!!!

XSA-335 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2020/08/24/xsa-335-qubes-not-affected/

The Xen Project has published Xen Security Advisory 335 (XSA-335). 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/#335

Xen Developer & Design Summit 2020 Virtual Event Recap
https://xenproject.org/2020/08/27/xen-developer-design-summit-2020-virtual-event-recap/

Last month, the Xen Project community gathered, virtually, to collaborate, connect, and solve the important challenges we all face. While our gathering may have looked different than in years past,...

Cache Coloring: Interference-free Real-time Virtualization
https://xenproject.org/2020/09/03/cache-coloring-interference-free-real-time-virtualization/

At this year’s Xen Developer and Design Summit, Stefano Stabellini from Xilinx gave a talk on Cache Coloring, a new feature for Xen that helps better support real-time workloads.  Many...

Qubes Canary #24
https://www.qubes-os.org/news/2020/09/10/canary-24/

We have published Qubes Canary #24. 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 #24 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-024-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 #24 ]===---


Statements
-----------

The Qubes core developers who have digitally signed this file [1]
state the following:

1. The date of issue of this canary is September 8, 2020.

2. There have been 58 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 December 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
-------------------

Tue, 08 Sep 2020 01:45:14 +0000

Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Germany Debates Halting Contentious Russian Pipeline Project
Monetary Policy Expert David Marsh: "We Are Witnessing the End of Independent Central Banks"
How Feces and Other Bodily Fluids Can Help Track COVID Outbreaks
Russian Patient: The Kremlin, Belarus and the Attack on Alexei Navalny
Nord Stream 2 Troubles: An Uncertain Future for the German-Russian Pipeline

Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Trump Emerges as Inspiration for Germany’s Far Right
Aided by Modern Ingenuity, a Taste of Ancient Judean Dates
Aleksei Navalny Out of a Coma and Responsive, German Doctors Say
London’s Bridges Really Are Falling Down
Truck Bomb in Somalia Kills 3 and Wounds 3, Including a U.S. Soldier

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Australian journalists flown out of China 'amid diplomatic standoff'
Michael Cohen's Trump book: The ex-lawyer's key claims
Russia's Navalny out of coma after poisoning
Wildfires burn through record area in California as blazes continue to spread
'They shot him in cold blood'

Source: Blockchain.info
00000000000000000005a914bdf7052f546448bd3459aa95b52bc1f1a62c27f6

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!

Get paid to support Qubes development through automated testing! (three-month contract)
https://www.qubes-os.org/news/2020/09/20/get-paid-to-support-qubes-development-through-automated-testing/

The Qubes OS Project is seeking an expert in automated testing. We use
OpenQA and Travis to test changes to the Qubes OS source code and
automated building from source. We’re looking for someone who can help
with improving both the automated tests themselves and the testing
infrastructure.

This is a paid position on a three-month part-time contract through the
Internews BASICS project (Building Analytical and Support Infrastructure
for Critical Security tools):

https://chm.tbe.taleo.net/chm04/ats/careers/v2/viewRequisition?org=INTERNEWS&cws=38&rid=1186

QSB #059: Multiple Xen issues (XSA-337, XSA-340, XSA-343)
https://www.qubes-os.org/news/2020/09/22/qsb-059/

We have just published Qubes Security Bulletin (QSB) #059:
Multiple Xen issues (XSA-337, XSA-340, XSA-343).
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 #059 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-059-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 the associated XSAs in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#337
https://www.qubes-os.org/security/xsa/#340
https://www.qubes-os.org/security/xsa/#343



---===[ Qubes Security Bulletin #59 ]===---

2020-09-22


Multiple Xen issues (XSA-337, XSA-340, XSA-343)


Summary
========

On 2020-09-22, the Xen Security Team published the following Xen
Security Advisories (XSAs):

XSA-337 [1] "PCI passthrough code reading back hardware registers":
| Code paths in Xen's MSI handling have been identified which act on
| unsanitized values read back from device hardware registers. While
| devices strictly compliant with PCI specifications shouldn't be able
| to affect these registers, experience shows that it's very common for
| devices to have out-of-spec "backdoor" operations which can affect the
| result of these reads.
|
| A not fully trusted guest may be able to crash Xen, leading to a
| Denial of Service (DoS) for the entire system. Privilege escalation
| and information leaks cannot be excluded.

XSA-340 [2] "Missing memory barriers when accessing/allocating an event
channel":
| Event channels control structures can be accessed lockless as long as
| the port is considered to be valid. Such sequence is missing
| appropriate memory barrier (e.g smp_*mb()) to prevent both the
| compiler and CPU to re-order access.
|
| A malicious guest may be able to cause a hypervisor crash resulting in
| a Denial of Service (DoS). Information leak and privilege escalation
| cannot be excluded.

XSA-343 [3] "races with evtchn_reset()":
| Uses of EVTCHNOP_reset (potentially by a guest on itself) or
| XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the
| violation of various internal assumptions. This may lead to out of
| bounds memory accesses or triggering of bug checks.
|
| In particular x86 PV guests may be able to elevate their privilege to
| that of the host. Host and guest crashes are also possible, leading
| to a Denial of Service (DoS). Information leaks cannot be ruled out.

Impact
=======

XSA-337: A malicious HVM with a PCI device (such as sys-net or sys-usb
in the default Qubes OS configuration) can potentially compromise the
whole system.

XSA-340: A malicious VM can exploit this vulnerability to crash Qubes
OS, resulting in a Denial of Service (DoS). This would require winning
a tight race condition. Beyond DoS, it is very unlikely that this
vulnerability could be exploited to compromise the system, but we
cannot completely rule out the possibility.

XSA-343: By default, Qubes OS uses PV domains only as stubdomains
hosting qemu for HVM domains. Therefore, in the default configuration,
an adversary cannot exploit this vulnerability directly. However, if an
adversary were also able to identify a complementary qemu vulnerability,
then chaining the attacks together could theoretically allow the
adversary to compromise the whole system. Although Qubes OS does not
contain any PV domains by default, users can create them manually by
setting the virt_mode property to PV. Such domains can exploit this
vulnerability directly.

Patching
=========

The specific packages that resolve the problems discussed in this
bulletin are as follows:

For Qubes 4.0:
- Xen packages, version 4.8.5-23

For Qubes 4.1:
- Xen packages, version 4.14.0-4

The packages are to be installed in dom0 via the Qube 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
Xen binaries.


Credits
========

See the original Xen Security Advisory.


References
===========

[1] https://xenbits.xen.org/xsa/advisory-337.html
[1] https://xenbits.xen.org/xsa/advisory-340.html
[1] https://xenbits.xen.org/xsa/advisory-343.html

--
The Qubes Security Team
https://www.qubes-os.org/security/

XSAs 333, 334, 336, 338, 339, 342, and 344 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2020/09/22/xsa-333-334-336-338-339-342-344-qubes-not-affected/

The Xen Project has published the following Xen Security Advisories:
XSA-333, XSA-334, XSA-336, XSA-338, XSA-339, XSA-342, and XSA-344.
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/#333
https://www.qubes-os.org/security/xsa/#334
https://www.qubes-os.org/security/xsa/#336
https://www.qubes-os.org/security/xsa/#338
https://www.qubes-os.org/security/xsa/#339
https://www.qubes-os.org/security/xsa/#342
https://www.qubes-os.org/security/xsa/#344