Introduction to Qubes this Saturday at the 35th CCC in Leipzig
https://www.qubes-os.org/news/2018/12/27/introduction-to-qubes-at-35c3/

Wojtek Porczyk (https://www.qubes-os.org/team/#wojtek-porczyk) will be hosting an “Introduction to Qubes OS” (https://events.ccc.de/congress/2018/wiki/index.php/Session:Introduction_to_Qubes_OS) workshop this
Saturday (2018-12-29) at the 35th Chaos Communication Congress (35C3) (https://events.ccc.de/congress/2018/wiki/index.php/Main_Page) in
Leipzig, Germany. We’ll start with the absolute basics and build from there; no
prior knowledge needed! All are welcome!

Fedora 29 TemplateVM available for Qubes 4.0
https://www.qubes-os.org/news/2019/01/07/fedora-29-template-available/

A new Fedora 29 TemplateVM is now available for Qubes 4.0. We
previously announced that Fedora 27 reached EOL (https://www.qubes-os.org/news/2018/11/30/fedora-27-eol/) and encouraged users
to upgrade to Fedora 28. Fedora 28 is still supported by the Fedora
Project, so users may now choose either Fedora 28 or 29 (or both)
depending on their needs and preferences. Instructions are available
for upgrading from Fedora 28 to 29 (https://www.qubes-os.org/doc/template/fedora/upgrade-28-to-29/). We also provide fresh Fedora 29
TemplateVM packages through the official Qubes repositories, which you
can get with the following commands (in dom0).

Standard Fedora 29 TemplateVM:

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


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

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


After upgrading to a Fedora 29 TemplateVM, please remember to set all
qubes that were using the old template to use the new one. This can be
done in dom0 either with the Qubes Template Manager (https://www.qubes-os.org/doc/templates/#how-to-switch-templates-40) or with the
qvm-prefs command-line tool.

Comment on Celebrating 15 Years of the Xen Project and Our Future by Lars Kurth
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-572

Hi,
when you talk about Xen, do you mean Xen Project or XenServer. Some of what you say seems to be related to XenServer, which is a commercial product built on top of Xen
Lars

Qubes Canary #18
https://www.qubes-os.org/news/2019/01/08/canary-18/

Dear Qubes Community,

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

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


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

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

1. The date of issue of this canary is January 8, 2019.

2. There have been 45 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 April 2019. 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
----------------------

Simon Gaiser (aka HW42) joined the Qubes Security Team. More details:
https://www.qubes-os.org/news/2018/11/05/qubes-security-team-update/

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
-------------------

$ date -R -u
Tue, 08 Jan 2019 03:18:51 +0000

$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Avi Loeb on the Mysterious Interstellar Body 'Oumuamua: 'Thinking About Distant Civilizations Isn't Speculative'
The Year of Populism: Europe's Right Wing Takes Aim at the EU
Women in Startups: 'The Most Successful Teams Are Diverse Teams'
Fergus Falls: A Fantastic Town
The Claas Relotius Affair: DER SPIEGEL's Reaction to U.S. Ambassador's Criticism

$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
Philippines Dispatch: Where 518 Inmates Sleep in Space for 170, and Gangs Hold It Together
Migrants’ Despair Is Growing at U.S. Border. So Are Smugglers’ Profits.
Poland Cracks Down on Escape Rooms After Diversion Turns Deadly
Kim Jong-un, North Korea’s Leader, Visits China
Fleeing Saudi Woman, Facing Deportation, Is Allowed to Remain in Thailand

$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
North Korea's Kim Jong-un visits China's Xi Jinping
Ex-Nissan boss says he is wrongly accused
Guatemala expels UN-backed anti-corruption commission
Yellow vests: France to crack down on unsanctioned protests

Kevin Spacey in court to face charges of groping teenager

$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
North Korea leader visits China after warning of alternate path to U.S. talks
Myanmar's civilian, military leaders meet, vow to "crush" Rakhine rebels
Guatemala to shut down U.N. anti-corruption body early
Trump, Trudeau agree to press China on detained Canadians: Ottawa
White House says Trump position unchanged as Syria withdrawal plans slow

$ curl -s 'https://blockchain.info/blocks/?format=json' |\
python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
000000000000000000073048d01300bb6ca9102dd0641f065cb42d5659412915

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!

Qubes OS 4.0.1 has been released!
https://www.qubes-os.org/news/2019/01/09/qubes-401/

We’re pleased to announce the release of Qubes 4.0.1! This is the first
stable point release of Qubes 4.0. It includes many updates over the
initial 4.0 release, in particular:

All 4.0 dom0 updates to date, including a lot of bug fixes and
improvements for GUI tools
Fedora 29 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Qubes 4.0.1 is available on the Downloads (https://www.qubes-os.org/downloads/) page.

What is a point release?

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

What should I do?

If you’re currently using an up-to-date Qubes 4.0 installation
(including updated Fedora 29, Debian 9, and Whonix 14 templates), then
your system is already equivalent to a Qubes 4.0.1 installation. No
action is needed.

Similarly, if you’re currently using a Qubes 4.0.1 release candidate
(4.0.1-rc1 or 4.0.1-rc2), and you’ve followed the standard procedure for
keeping it up-to-date, then your system is equivalent to a 4.0.1 stable
installation, and no additional action is needed.

If you’re currently using Qubes 4.0 but don’t have these new templates
installed yet, we recommend that you follow the appropriate
documentation to do so:

Fedora 29 (https://www.qubes-os.org/doc/template/fedora/upgrade-28-to-29/)
Debian 9 (https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/)
Whonix 14 (https://www.whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14)
Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.1 ISO will make this more
convenient and secure, since it bundles all Qubes 4.0 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 4.0 installer.

XSA-289 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2019/01/21/xsa-289-qubes-not-affected/

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

XSA-289 is unusual in that it does not disclose any new
vulnerabilities. Rather, it is only for the purpose of providing
information about previously-disclosed vulnerabilities. These
vulnerabilities were all patched in Qubes OS as part of QSB #43 (https://www.qubes-os.org/news/2018/09/02/qsb-43/),
which we published on 2018-09-02. Therefore, XSA-289 does not affect
the security of updated Qubes OS installations.

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

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

QSB #46: APT update mechanism vulnerability
https://www.qubes-os.org/news/2019/01/23/qsb-46/

We have just published Qubes Security Bulletin (QSB) #46: APT update mechanism
vulnerability. 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 #46 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-046-2019.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/



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

2019-01-23

APT update mechanism vulnerability


Summary
========

The Debian Security Team has announced a security vulnerability
(DSA-4371-1) in the Advanced Package Tool (APT). The vulnerability lies
in the way APT performs HTTP redirect handling when downloading
packages. Exploitation of this vulnerability could lead to privilege
escalation [1] inside an APT-based VM, such as a Debian or Whonix VM.
This bug does _not_ allow escape from any VM or enable any attacks on
other parts of the Qubes system. In particular, this bug does _not_
affect dom0, the Xen hypervisor, or any non-APT-based VMs. Nevertheless,
we have decided to release this bulletin, because if a TemplateVM is
affected, then every VM based on that template is affected.


Denoscription
============

As described in [1]:

| Max Justicz discovered a vulnerability in APT, the high level package
| manager. The code handling HTTP redirects in the HTTP transport
| method doesn't properly sanitize fields transmitted over the wire.
| This vulnerability could be used by an attacker located as a
| man-in-the-middle between APT and a mirror to inject malicious content
| in the HTTP connection. This content could then be recognized as a
| valid package by APT and used later for code execution with root
| privileges on the target machine.


Impact
=======

Users who use Debian or Whonix VMs are affected. Users who use only
Fedora VMs are not affected. Although we do not provide any other
official or community APT-based templates, any other APT-based VMs that
users have installed on their own should also be assumed to be affected.


Discussion
===========

Normally, we do not release Qubes Security Bulletins (QSBs) to address
vulnerabilities that only affect VMs internally without affecting the
rest of the Qubes system, i.e. vulnerabilities that do not undermine the
Qubes security model.

For example, we do not release QSBs to address bugs in Firefox or Linux
kernel USB stacks, because Qubes OS was designed under the primary
assumption that in a typical desktop OS there will be countless such
bugs and that humankind will never be able to patch all of them promptly
(at least not as quickly as developers introduce new bugs). This is, in
fact, the very reason we designed Qubes OS as an implementation of the
security-by-compartmentalization approach.

The APT update bug discussed today is, however, somewhat special.
While it is indeed a bug that only affects VMs internally, it could
allow an attacker to compromise TemplateVMs, which are used as a basis
for creating other VMs, such as AppVMs and ServiceVMs. If a TemplateVM
is compromised, then all the VMs based on that TemplateVM will be
compromised. Since AppVMs operate directly on user data, and since
ServiceVMs can be critical to user privacy (especially in the case of
Whonix and VPN ProxyVMs), this is a serious matter.

In Qubes OS, we take special precautions to make TemplateVMs difficult
to compromise. For example, we block all network connections to and from
templates, with one exception: We allow templates to connect to the
so-called "Update Proxy" (which runs in the NetVM). This allows the
TemplateVM to retrieve updates while protecting users from accidentally

using TemplateVMs to perform risky activities, such as browsing the web.

Since the bug under discussion has the potential to subvert this very
protection mechanism, we've decided to issue this QSB.

We would like to point out, however, that Qubes OS does a good job of
mitigating this kind of a vulnerability. Instead of having to reinstall
the whole operating system from scratch, Qubes users may need only to
reinstall the affected template(s).

If users are concerned that potential attackers may have compromised not
only the root filesystem of the template, but also attempted to infect
user files in AppVM filesystems (e.g. ~/.bashrc or a Web browser profile
directory), Qubes allows for mounting each of the suspected AppVM
private images into a different, trusted VM, based on a trusted
template, for "offline" analysis and cleanup, allowing users to preserve
their data.


Patching
=========

If you are a Qubes user, you should remove all APT-based (including
Debian and Whonix) TemplateVMs and StandaloneVMs, then install fresh
ones. You can do this by performing the following steps on each such
TemplateVM:

1. Note any customizations you have made to the target TemplateVM.

2. Temporarily change all VMs based on the target TemplateVM to a
different template, or remove them.

Temporarily switching to a different template can be a good idea if
you have user data in these VMs that you want to keep. On the other
hand, if you suspect that these VMs are compromised, you may want to
remove them instead. You can remove them in Qube(s) Manager by
right-clicking on the VM and clicking "Remove VM" or "Delete qube,"
or you can use this command in dom0:

$ qvm-remove

3. Uninstall the target TemplateVM from dom0:

$ sudo dnf remove

This requires specifying the template package name (not the
TemplateVM's name). A list of affected template package names is
provided below. For example, to uninstall the whonix-gw-14 template:

$ sudo dnf remove qubes-template-whonix-gw-14

4. Reinstall the target TemplateVM in dom0:

$ sudo qubes-dom0-update --enablerepo= \


This requires specifying the template package name (not the
TemplateVM's name). A list of new (fixed) template package names is
provided below. For example, to install the whonix-gw-14
template:

$ sudo qubes-dom0-update --enablerepo=qubes-templates-community \
qubes-template-whonix-gw-14

Then verify the right version was installed:

$ rpm -q qubes-template-whonix-gw-14
qubes-template-whonix-gw-14-4.0.1-201901231238.noarch

In accordance with our standard policy, new (fixed) template packages
will first reside in the testing repositories for approximately two
weeks before migrating to the stable repositories. In order to
install a templates package from its testing repository, you must
enable that repository. For example, to install the whonix-gw-14
template from its testing repository:

$ sudo qubes-dom0-update \
--enablerepo=qubes-templates-community-testing \
qubes-template-whonix-gw-14

5. If you temporarily changed all VMs based on the target TemplateVM to
a different template in step 2, change them back to the fresh
TemplateVM now. If you instead removed all VMs based on the old
TemplateVM, you can recreate your desired VMs from the fresh
TemplateVM now.

6. If you noted any template customizations in step 1, clone the target
TemplateVM, then reapply your customizations to the clone.

Old (vulnerable) and new (fixed) Qubes TemplateVM packages are listed
for each supported Qubes OS version in the tables below:

Qubes 4.0:
+------------------------------------------------------------------------------+
| Old (Vulnerable) | New (Fixed) |
| --------------------------- | ---------------------------------------------- |
| qubes-template-debian-8 | qubes-template-debian-8-4.0.1-201901231241 |

| qubes-template-debian-9 | qubes-template-debian-9-4.0.1-201901230644 |
| qubes-template-whonix-gw-14 | qubes-template-whonix-gw-14-4.0.1-201901231238 |
| qubes-template-whonix-ws-14 | qubes-template-whonix-ws-14-4.0.1-201901231238 |
+------------------------------------------------------------------------------+

Qubes 3.2:
+--------------------------------------------------------------------------+
| Old (Vulnerable) | New (Fixed) |
| --------------------------- | ------------------------------------------ |
| qubes-template-debian-8 | qubes-template-debian-8-4.0.1-201901230645 |
| qubes-template-debian-9 | qubes-template-debian-9-4.0.1-201901230645 |
| qubes-template-whonix-gw-14 | not supported |
| qubes-template-whonix-ws-14 | not supported |
+--------------------------------------------------------------------------+


Alternative patching for non-critical TemplateVMs
==================================================

Users who do not rely on APT-based VMs for any critical tasks may
instead opt just to install fixed APT packages. This is _not_ secure if
the template has already been compromised. If you are not willing to
take the risk that the template may already be compromised, you should
instead follow the instructions in the previous section to completely
remove the template, then install a fresh one.

As the bug is present in the update mechanism itself, special care
should be taken while performing the update, as described in [1]. We
include those steps in GUI tools used to update, so updating the GUI
tools and performing the template update with either of them will also
apply the fix in a safe way, as long as the TemplateVM is not already
compromised.

Important: Listed below are the minimum package versions that will
perform APT updates safely. However, after installing these packages,
you must also update all APT-based TemplateVMs normally through the
Qubes VM Manager. Installing the packages listed below is not enough.

Qubes 4.0:
- qubes-desktop-linux-manager 4.0.14 (updates widget)
- qubes-manager 4.0.27 (Qube Manager)

Qubes 3.2:
- qubes-manager 3.2.14 (Qubes VM Manager)

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

Now you can safely update your APT-based TemplateVMs through the Qubes
VM Manger.


Credits
========

This vulnerability was discovered by Max Justicz and reported to the
Debian Security Team.


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

[1] https://www.debian.org/security/2019/dsa-4371


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

There will be a Qubes talk / demo at Join me at Stockholm Cybersecurity Meetup February http://meetu.ps/e/G0XM5/wxTFj/a in Stockholm end of next month

Xen Project Developer and Design Summit: Registration Open Now
https://blog.xenproject.org/2019/01/30/xen-project-developer-and-design-summit-registration-open-now/

Starting today, registration officially opens for The Xen Project Developer & Design Summit. This year’s Summit, taking place from July 9 through 11 in Chicago, will bring together the Xen Project community of developers and power users to share ideas, latest developments, and experiences, as well as offer opportunities to plan and collaborate on all […]

Xen Project Celebrates Unikraft Unikernel Project’s One Year Anniversary
https://blog.xenproject.org/2019/01/31/xen-project-celebrates-unikraft-unikernel-projects-one-year-anniversary/

It has been one year since the Xen Project introduced Unikraft as an incubator project. In that time, the team has made great strides in simplifying the process of building unikernels through a unified and customizable code base. Unikraft is an incubation project under the Xen Project, hosted by the Linux Foundation, focused on easing […]

Comment on Xen Project Celebrates Unikraft Unikernel Project’s One Year Anniversary by Xen Project Celebrates Unikraft Unikernel Project's One Year Anniversary | Linux.com | Top Tech Stories
https://blog.xenproject.org/2019/01/31/xen-project-celebrates-unikraft-unikernel-projects-one-year-anniversary/#comment-574

[…] This article in the beginning seemed at Xen Project. […]

Comment on Xen Project Celebrates Unikraft Unikernel Project’s One Year Anniversary by Xen Project Celebrates Unikraft Unikernel Project’s One Year Anniversary |
https://blog.xenproject.org/2019/01/31/xen-project-celebrates-unikraft-unikernel-projects-one-year-anniversary/#comment-575

[…] This article originally appeared at Xen Project. […]

QSB #47: Insecure default DisposableVM networking configuration
https://www.qubes-os.org/news/2019/02/19/qsb-47/

We have just published Qubes Security Bulletin (QSB) #47: Insecure default
DisposableVM networking configuration. 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 #47 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-047-2019.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/



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

2019-02-19

Insecure default DisposableVM networking configuration

Summary
========

In Qubes OS, one can attempt to limit the network access of a qube by
either completely disconnecting it from any NetVM or by setting its
firewall rules to disallow access. A malicious qube can circumvent these
limits by launching a DisposableVM [1], which, in the default
configuration, would have unrestricted network access.

Moreover, even when a non-default DisposableVM is configured to have no
network access (or limited access), other DisposableVMs started from
_that_ DisposableVM can have full network access (unless explicitly
configured otherwise).

While limiting network access in this manner should not be considered to
be an effective leak-prevention mechanism [1], we still consider this
type of potentially ineffective network isolation to be a problem.

Details
========

In Qubes 4.0, each DisposableVM is based on a DVM Template [2] with the
`template_for_dispvm` property set to "True". The DisposableVM inherits
all of its settings from the DVM Template, including the `netvm`
property and firewall rules. Neither the network settings nor any other
settings of the calling qube are considered. This design is intentional,
as it allows much more flexibility over the previous model. For example,
one could create different DVM Templates for different purposes, such as
opening links (internet access), viewing documents (offline), printing
(drivers installed), etc. Each DVM Template has appropriate network
settings for its purpose.

The important part of this design is the `default_dispvm` qube property.
The value of this property is the DVM Template that will be used when
starting new DisposableVMs from that qube. In the default configuration,
Qubes OS has one default DVM Template, which has unrestricted network
access. The default DVM Template is the default value of the global
`default_dispvm` property, which is accessible via "Global settings" in
the Qube Manager or via the `qubes-prefs` tool. This global property
serves as the default value for the `default_dispvm` property for every
qube. If the user creates a non-default DVM Template with limited
network access, the user must also set the `default_dispvm` value
(either globally or on a per-qube basis) in order for any new
DisposableVM to be based on this non-default DVM Template.

In the Whonix configuration shipped with Qubes, this issue is avoided by
creating a separate DVM Template that uses the Whonix Gateway
(`sys-whonix`) as its NetVM. The `default_dispvm` property of this DVM
Template is set to itself. This DVM Template is the value of the
`default_dispvm` property for every Whonix Workstation.

This problem is partially mitigated when restoring a backup from Qubes
3.2. For each qube that has the `dispvm_netvm` property set to "none", a
separate DVM Template named `disp-no-netvm` is created. This DVM
Template has no direct network access. However, this DVM Template itself
has the default value for its own `default_dispvm` property, so
DisposableVMs started from it or from DisposableVMs based on it would
have full network access.

Vulnerable systems
==================

This issue affects only Qubes 4.0. In Qubes 3.2, the network settings of
DisposableVM are inherited from the calling qube's settings (more
specifically, from its `dispvm_netvm` property, which defaults to the
`netvm` property's value).

The Whonix configuration shipped with Qubes 4.0 is not affected by this
issue. If you have installed Whonix using a method other than the
recommended `qubesctl` command [4], you should review the settings of
your Whonix qubes. Specifically:

- whonix-ws-14-dvm should have `netvm` set to sys-whonix
- whonix-ws-14-dvm should have `default_dispvm` set to whonix-ws-14-dvm
- anon-whonix and any other Whonix Workstations should have
`default_dispvm` set to whonix-ws-14-dvm

See the Whonix documentation [4] for details.

Systems in which the default DVM Template is disconnected from the
network (by settings its `netvm` property to "none") are not affected by
this issue.

Resolution
==========

To mitigate this problem, we are implementing two changes:

1. When a DisposableVM is started, automatically set its
`default_dispvm` to the DVM Template on which it is based. This means
that, when a DisposableVM is started from another DisposableVM, they
will both be based on the same DVM Template. Hence, they will have
all the same settings, including the same network settings. This
change will not affect DVM Templates for which user has manually
modified the `default_dispvm` property.

2. Add a warning message in the Qube Settings GUI when the NetVM of a
qube in the "Basic" tab is set to a different value than the NetVM of
the default DVM Template set in the "Advanced" tab.

Note that these changes concern only NetVM settings, not firewall
settings. If you want your DisposableVMs to have the same firewall
settings as the calling qube, you must adjust the firewall settings of
appropriate DVM Template yourself.

In the next version of Qubes, we will ship two DVM Templates by default:
one with network access and one without. This was already previously
discussed in issue #1121 [5].

Patching
=========

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

For Qubes OS 4.0:
- qubes-core-dom0 version 4.0.39
- qubes-manager version 4.0.28

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

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.

Credits
========

The issue was reported by Vít 'v6ak' Šesták.

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

[1] https://www.qubes-os.org/doc/disposablevm/
[2] https://www.qubes-os.org/doc/data-leaks/
[3] https://www.qubes-os.org/doc/glossary/#dvm-template
[4] https://www.whonix.org/wiki/Qubes/Install
[5] https://github.com/QubesOS/qubes-issues/issues/1121

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

Qubes OS 3.2 approaching EOL on 2019-03-28
https://www.qubes-os.org/news/2019/02/20/qubes-3-2-approaching-eol/

Qubes OS releases are normally supported (https://www.qubes-os.org/doc/supported-versions/) for six months after each
subsequent major or minor release (https://www.qubes-os.org/doc/version-scheme/). However, in light of the more
demanding system requirements (https://www.qubes-os.org/doc/system-requirements/#qubes-release-4x) of Qubes 4.0, we previously announced
that we were extending (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/#extended-support-for-qubes-os-32) the support period for Qubes 3.2 to one full
year after the release of Qubes 4.0. Since Qubes 4.0 was released (https://www.qubes-os.org/news/2018/03/28/qubes-40/) on
2018-03-28, support for Qubes 3.2 is extended until 2019-03-28 (https://www.qubes-os.org/news/2018/03/28/qubes-40/#the-past-and-the-future).

Therefore, we strongly urge all current Qubes 3.2 users to upgrade to
Qubes 4.0 (https://www.qubes-os.org/doc/upgrade-to-r4.0/) before Qubes 3.2 reaches end-of-life (EOL) on 2019-03-28.
As always, the latest release is available on the downloads (https://www.qubes-os.org/downloads/) page.

Xen Project 4.10.3 and 4.9.4 are available
https://blog.xenproject.org/2019/02/26/xen-project-4-10-3-and-4-9-4-are-available/

I am pleased to announce the release of Xen 4.10.3 and 4.9.4. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.10 and 4.9 stable series update to the latest point release. These releases are available from their git repositories xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.10 (tag RELEASE-4.10.3) xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9 […]

Talk about Qubes in Stockholm tonight: https://www.meetup.com/Stockholm-Cybersecurity-Meetup/events/dwjxrqyzdbkc/