XSA-278 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/10/24/xsa-278-qubes-not-affected/
Dear Qubes Community,
The Xen Project has published Xen Security Advisory 278 (XSA-278). 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/#278
https://www.qubes-os.org/news/2018/10/24/xsa-278-qubes-not-affected/
Dear Qubes Community,
The Xen Project has published Xen Security Advisory 278 (XSA-278). 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/#278
Thank you, Joanna!
https://www.qubes-os.org/news/2018/10/25/thank-you-joanna/
The Qubes OS project was founded by Joanna Rutkowska in 2009 (https://blog.invisiblethings.org/2010/04/07/introducing-qubes-os.html).
I joined the project in its early days, before Qubes 1.0, and have been part of
the team under Joanna’s leadership since then. Over the past nine years, the
system architecture has been enhanced multiple times, including major changes
like HVM with stubdomain support (https://blog.invisiblethings.org/2012/12/14/qubes-2-beta-1-with-initial-windows.html), the Hypervisor Abstraction Layer
(HAL) (https://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html), and finally, in Qubes 4.0, the Admin API (https://blog.invisiblethings.org/2017/06/27/qubes-admin-api.html) and switch
to PVH (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/) as the main VM type. The project has also matured a lot. We
started as a set of a few (https://github.com/QubesOS/qubes-doc/blob/6ac51fb134093168ec3900c9bed22c3a86bcd021/SourceCode.md) manually built (https://groups.google.com/d/msg/qubes-devel/cQ9yVxPMfoo/CTIXml3B_NcJ) packages
installed on top of Fedora 12 (https://github.com/QubesOS/qubes-doc/blob/d6639edf47a7b85e54cd470380de25e1b7403407/InstallationGuide.md). Now, we have a build
infrastructure (https://github.com/QubesOS/qubes-infrastructure/blob/master/README.md#detailed-denoscription-of-the-infrastructure), documented versioning scheme (https://www.qubes-os.org/doc/version-scheme/)
and release schedules (https://www.qubes-os.org/doc/releases/schedules/), coding guidelines (https://www.qubes-os.org/doc/coding-style/),
and automated tests (https://www.qubes-os.org/doc/automated-tests/). The core part of Qubes has also been
rewritten a few times since its original release. The project’s success can be
measured by its growing community, including deployments like SecureDrop (https://securedrop.org/news/road-towards-integrated-securedrop-workstation/) and
Let’s Encrypt (https://twitter.com/RMLLsec16/status/749982515948027904).
Today Joanna announced (https://www.qubes-os.org/news/2018/10/25/the-next-chapter/) that she is stepping down from the
project’s leadership role and nominating me as her successor. I have been the
project’s lead engineer for a few years now, and I’m honored to officially lead
the project as a whole. I plan to continue the direction in which Qubes OS has
been going, providing defenses well ahead (https://twitter.com/rootkovska/status/530416582426902528) of new attacks.
On behalf of the whole Qubes team, I’d like to thank Joanna for all of her
years of work on the project. Under her leadership, Qubes OS has accomplished a
lot, with only some of its many successes mentioned above. We look forward to
continuing to benefit from her expertise as an advisor. At the same time, we
wish her all the best in her new role on the Golem Project!
https://www.qubes-os.org/news/2018/10/25/thank-you-joanna/
The Qubes OS project was founded by Joanna Rutkowska in 2009 (https://blog.invisiblethings.org/2010/04/07/introducing-qubes-os.html).
I joined the project in its early days, before Qubes 1.0, and have been part of
the team under Joanna’s leadership since then. Over the past nine years, the
system architecture has been enhanced multiple times, including major changes
like HVM with stubdomain support (https://blog.invisiblethings.org/2012/12/14/qubes-2-beta-1-with-initial-windows.html), the Hypervisor Abstraction Layer
(HAL) (https://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html), and finally, in Qubes 4.0, the Admin API (https://blog.invisiblethings.org/2017/06/27/qubes-admin-api.html) and switch
to PVH (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/) as the main VM type. The project has also matured a lot. We
started as a set of a few (https://github.com/QubesOS/qubes-doc/blob/6ac51fb134093168ec3900c9bed22c3a86bcd021/SourceCode.md) manually built (https://groups.google.com/d/msg/qubes-devel/cQ9yVxPMfoo/CTIXml3B_NcJ) packages
installed on top of Fedora 12 (https://github.com/QubesOS/qubes-doc/blob/d6639edf47a7b85e54cd470380de25e1b7403407/InstallationGuide.md). Now, we have a build
infrastructure (https://github.com/QubesOS/qubes-infrastructure/blob/master/README.md#detailed-denoscription-of-the-infrastructure), documented versioning scheme (https://www.qubes-os.org/doc/version-scheme/)
and release schedules (https://www.qubes-os.org/doc/releases/schedules/), coding guidelines (https://www.qubes-os.org/doc/coding-style/),
and automated tests (https://www.qubes-os.org/doc/automated-tests/). The core part of Qubes has also been
rewritten a few times since its original release. The project’s success can be
measured by its growing community, including deployments like SecureDrop (https://securedrop.org/news/road-towards-integrated-securedrop-workstation/) and
Let’s Encrypt (https://twitter.com/RMLLsec16/status/749982515948027904).
Today Joanna announced (https://www.qubes-os.org/news/2018/10/25/the-next-chapter/) that she is stepping down from the
project’s leadership role and nominating me as her successor. I have been the
project’s lead engineer for a few years now, and I’m honored to officially lead
the project as a whole. I plan to continue the direction in which Qubes OS has
been going, providing defenses well ahead (https://twitter.com/rootkovska/status/530416582426902528) of new attacks.
On behalf of the whole Qubes team, I’d like to thank Joanna for all of her
years of work on the project. Under her leadership, Qubes OS has accomplished a
lot, with only some of its many successes mentioned above. We look forward to
continuing to benefit from her expertise as an advisor. At the same time, we
wish her all the best in her new role on the Golem Project!
The Next Chapter: From the Endpoint to the Cloud
https://www.qubes-os.org/news/2018/10/25/the-next-chapter/
Earlier this year, I decided to take a sabbatical. I wanted to reflect on my
infosec work and decide what I would like to focus on in the coming years. As
you probably know, I’ve spent the last nine years mostly fighting the battle to
secure the endpoint, more specifically creating, developing, architecting, and
promoting Qubes OS (https://www.qubes-os.org/), as well as the more general
concept of “Security through
Distrusting” (https://www.blackhat.com/eu-17/briefings.html#security-through-distrusting).
Over these past nine years, Qubes OS has grown from a research-inspired
proof-of-concept into a reasonably mature, large open-source project with
dozens of contributors (https://www.qubes-os.org/team/) and tens of thousands
of users (https://www.qubes-os.org/statistics/), including some high-profile
security experts (https://www.qubes-os.org/experts/).
There are still many challenges ahead for Qubes, however. The primary two are
improving hardware compatibility and UX. I think addressing these challenges
will mostly be an iterative process of gradual improvement, but it will
nonetheless require a lot of time and resources.
Another challenge is the trustworthiness of the x86
platform (https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf). Again,
I remain optimistic that many things could be improved on this front, as well
(see, for example, my proposal for a stateless laptop
design (https://blog.invisiblethings.org/papers/2015/state_harmful.pdf)).
Admittedly, such work will require significantly more resources, but I know
there is a lot of interest in this area, and it just needs proper coordination
to happen.
Despite all of these interesting challenges (especially with platform
trustworthiness), I’ve decided I’d like to switch my focus to something other
than endpoint security. While I still believe that the security of our digital
lives starts and ends with the trustworthiness of the client devices we use
(which today include much more than just laptops and desktops, of course), I
also recognize that the state of endpoint device security has significantly
improved over the past decade. At the same time, most of our data and activities
have migrated from local devices to the cloud.
And yet, there are fundamental problems with cloud
trustworthiness (https://twitter.com/rootkovska/status/1051392157096001536), or
the lack thereof. These problems could be summarized as the need for users (i.e.
all of us) to be forced to trust three different entities: (1) the service
providers who own our data (e.g. the vendor of your fitness tracking app), (2)
the hosting infrastructure owners, who can both access our data as well as deny
us use of the service at their discretion (e.g. AWS, Azure, GCP), and (3) the
networking infrastructure operators, who can also selectively cut us off from
the services (e.g. to implement some form of censorship).
These are very important problems, in my opinion, and I’d like to work now on
making the cloud more trustworthy, specifically by limiting the amount of trust
we have to place in it.
So, this month I’ve joined the Golem Project (https://golem.network/) as a
Chief Strategy Officer, also doubling as Chief Security Officer (conveniently,
both roles have the same CSO acronym :) The double nature of my role emphasizes
the close relationships among the long-term roadmap, technical architecture,
as well as product- and operations-security in Golem.
Why Golem? Because Golem is a very unique project. Golem has been on a mission
to build a “decentralized computer” out of a heterogeneous network of
third-party provided computers. Founded two years ago through a very successful
crowdfunding campaign, it instantly gained an impressive amount of funding,
which allowed it to build a strong development team (incidentally, mostly based
in my favorite city – Warsaw).
https://www.qubes-os.org/news/2018/10/25/the-next-chapter/
Earlier this year, I decided to take a sabbatical. I wanted to reflect on my
infosec work and decide what I would like to focus on in the coming years. As
you probably know, I’ve spent the last nine years mostly fighting the battle to
secure the endpoint, more specifically creating, developing, architecting, and
promoting Qubes OS (https://www.qubes-os.org/), as well as the more general
concept of “Security through
Distrusting” (https://www.blackhat.com/eu-17/briefings.html#security-through-distrusting).
Over these past nine years, Qubes OS has grown from a research-inspired
proof-of-concept into a reasonably mature, large open-source project with
dozens of contributors (https://www.qubes-os.org/team/) and tens of thousands
of users (https://www.qubes-os.org/statistics/), including some high-profile
security experts (https://www.qubes-os.org/experts/).
There are still many challenges ahead for Qubes, however. The primary two are
improving hardware compatibility and UX. I think addressing these challenges
will mostly be an iterative process of gradual improvement, but it will
nonetheless require a lot of time and resources.
Another challenge is the trustworthiness of the x86
platform (https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf). Again,
I remain optimistic that many things could be improved on this front, as well
(see, for example, my proposal for a stateless laptop
design (https://blog.invisiblethings.org/papers/2015/state_harmful.pdf)).
Admittedly, such work will require significantly more resources, but I know
there is a lot of interest in this area, and it just needs proper coordination
to happen.
Despite all of these interesting challenges (especially with platform
trustworthiness), I’ve decided I’d like to switch my focus to something other
than endpoint security. While I still believe that the security of our digital
lives starts and ends with the trustworthiness of the client devices we use
(which today include much more than just laptops and desktops, of course), I
also recognize that the state of endpoint device security has significantly
improved over the past decade. At the same time, most of our data and activities
have migrated from local devices to the cloud.
And yet, there are fundamental problems with cloud
trustworthiness (https://twitter.com/rootkovska/status/1051392157096001536), or
the lack thereof. These problems could be summarized as the need for users (i.e.
all of us) to be forced to trust three different entities: (1) the service
providers who own our data (e.g. the vendor of your fitness tracking app), (2)
the hosting infrastructure owners, who can both access our data as well as deny
us use of the service at their discretion (e.g. AWS, Azure, GCP), and (3) the
networking infrastructure operators, who can also selectively cut us off from
the services (e.g. to implement some form of censorship).
These are very important problems, in my opinion, and I’d like to work now on
making the cloud more trustworthy, specifically by limiting the amount of trust
we have to place in it.
So, this month I’ve joined the Golem Project (https://golem.network/) as a
Chief Strategy Officer, also doubling as Chief Security Officer (conveniently,
both roles have the same CSO acronym :) The double nature of my role emphasizes
the close relationships among the long-term roadmap, technical architecture,
as well as product- and operations-security in Golem.
Why Golem? Because Golem is a very unique project. Golem has been on a mission
to build a “decentralized computer” out of a heterogeneous network of
third-party provided computers. Founded two years ago through a very successful
crowdfunding campaign, it instantly gained an impressive amount of funding,
which allowed it to build a strong development team (incidentally, mostly based
in my favorite city – Warsaw).
The distributed funding model has also essentially eliminated two common
obstacles most tech startups face: lack of money to hire enough people and the
need to implement investors’ (rather than the founders’) agenda. In this
respect Golem seems to be as independent as one could realistically imagine.
Most importantly, we (ITL), have already been
working (https://blog.invisiblethings.org/2018/06/11/graphene-ng.html) with
Golem over the past year. During that time I’ve had enough time to get to know
some of the key people in the project, understand their personal agendas, and
conclude they might be very much inline with my own.
As for the future of Qubes, I don’t think much will change here. In recent
years, Marek
Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki)
has been effectively leading most of the day-to-day efforts with Qubes OS
development, while I’ve focused mostly on long-term architecture planning and
various research activities, such as our SGX-related work. Marek will continue
to lead Qubes now, so I’m reassured about the future of the project. I will also
remain as an advisor to the Qubes OS Project, as well as… its user, though I’ve
recently also been embracing other systems, including – of course – the cloud.
Finally, I’d like to thank my (present and past) ITL colleagues. We have
undertaken quite a few projects together, of which Qubes OS is probably the most
challenging and spectacular. Yet it was hardly the only one. There was also all
the (allegedly
pioneering (https://twitter.com/dwizzzleMSFT/status/1006733071511519232))
offensive system security research done together with Rafał Wojtczuk and Alex
Tereshkin. This research was instrumental in our subsequent work on Qubes OS,
and I think it will again prove useful for my work on Golem.
obstacles most tech startups face: lack of money to hire enough people and the
need to implement investors’ (rather than the founders’) agenda. In this
respect Golem seems to be as independent as one could realistically imagine.
Most importantly, we (ITL), have already been
working (https://blog.invisiblethings.org/2018/06/11/graphene-ng.html) with
Golem over the past year. During that time I’ve had enough time to get to know
some of the key people in the project, understand their personal agendas, and
conclude they might be very much inline with my own.
As for the future of Qubes, I don’t think much will change here. In recent
years, Marek
Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki)
has been effectively leading most of the day-to-day efforts with Qubes OS
development, while I’ve focused mostly on long-term architecture planning and
various research activities, such as our SGX-related work. Marek will continue
to lead Qubes now, so I’m reassured about the future of the project. I will also
remain as an advisor to the Qubes OS Project, as well as… its user, though I’ve
recently also been embracing other systems, including – of course – the cloud.
Finally, I’d like to thank my (present and past) ITL colleagues. We have
undertaken quite a few projects together, of which Qubes OS is probably the most
challenging and spectacular. Yet it was hardly the only one. There was also all
the (allegedly
pioneering (https://twitter.com/dwizzzleMSFT/status/1006733071511519232))
offensive system security research done together with Rafał Wojtczuk and Alex
Tereshkin. This research was instrumental in our subsequent work on Qubes OS,
and I think it will again prove useful for my work on Golem.
Qubes OS 4.0.1-rc1 has been released!
https://www.qubes-os.org/news/2018/11/05/qubes-401-rc1/
We’re pleased to announce the first release candidate for Qubes 4.0.1!
This is the first of at least two planned point releases for version 4.0.
Features:
All 4.0 dom0 updates to date
Fedora 29 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Qubes 4.0.1-rc1 is available on the Downloads (https://www.qubes-os.org/downloads/#qubes-release-4-0-1-rc1) 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, then
your system is already equivalent to a Qubes 4.0.1 installation. No
action is needed.
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.
Release candidate planning
We expect that there will be a second release candidate (4.0.1-rc2) following
this one (4.0.1-rc1). The second release candidate will include a fix for the
Nautilus bug reported in #4460 (https://github.com/QubesOS/qubes-issues/issues/4460) along with any other available fixes for bugs
reported against this release candidate. As usual, you can help by reporting
any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/).
What about Qubes 3.2.1?
We announced the release of 3.2.1-rc1 one month ago (https://www.qubes-os.org/news/2018/10/05/qubes-321-rc1/). Since no serious
problems have been discovered in 3.2.1-rc1, we plan to build the final version
of Qubes 3.2.1 at the end of this week.
https://www.qubes-os.org/news/2018/11/05/qubes-401-rc1/
We’re pleased to announce the first release candidate for Qubes 4.0.1!
This is the first of at least two planned point releases for version 4.0.
Features:
All 4.0 dom0 updates to date
Fedora 29 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Qubes 4.0.1-rc1 is available on the Downloads (https://www.qubes-os.org/downloads/#qubes-release-4-0-1-rc1) 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, then
your system is already equivalent to a Qubes 4.0.1 installation. No
action is needed.
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.
Release candidate planning
We expect that there will be a second release candidate (4.0.1-rc2) following
this one (4.0.1-rc1). The second release candidate will include a fix for the
Nautilus bug reported in #4460 (https://github.com/QubesOS/qubes-issues/issues/4460) along with any other available fixes for bugs
reported against this release candidate. As usual, you can help by reporting
any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/).
What about Qubes 3.2.1?
We announced the release of 3.2.1-rc1 one month ago (https://www.qubes-os.org/news/2018/10/05/qubes-321-rc1/). Since no serious
problems have been discovered in 3.2.1-rc1, we plan to build the final version
of Qubes 3.2.1 at the end of this week.
Qubes Security Team Update
https://www.qubes-os.org/news/2018/11/05/qubes-security-team-update/
As we recently announced, Joanna Rutkowska (https://www.qubes-os.org/team/#joanna-rutkowska) has turned over leadership of the
Qubes OS Project to Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki) (see Joanna’s announcement (https://www.qubes-os.org/news/2018/10/25/the-next-chapter/)
and Marek’s announcement (https://www.qubes-os.org/news/2018/10/25/thank-you-joanna/)). In this post, we’ll discuss the implications of
these changes for the Qubes Security Team and how we’re addressing them.
What is the Qubes Security Team?
The Qubes Security Team (QST) (https://www.qubes-os.org/security/#the-qubes-security-team) is the subset of the Qubes Team (https://www.qubes-os.org/team/) that is
responsible for ensuring the security of Qubes OS and the Qubes OS Project.
In particular, the QST is responsible for:
Responding to reported security issues (https://www.qubes-os.org/security/#reporting-security-issues-in-qubes-os)
Evaluating whether Xen Security Advisories (XSAs) (https://www.qubes-os.org/security/xsa/) affect the security of
Qubes OS
Writing, applying, and/or distributing security patches to fix
vulnerabilities in Qubes OS
Writing, signing, and publishing Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
Writing, signing, and publishing Qubes Canaries (https://www.qubes-os.org/security/canaries/)
Generating, safeguarding, and using the project’s PGP keys (https://keys.qubes-os.org/keys/)
As a security-oriented operating system, the QST is fundamentally important to
Qubes, and every Qubes user implicitly trusts the members of the QST by virtue
of the actions listed above.
How does the recent change in leadership affect the QST?
Until now, the two members of the QST have been Joanna and Marek. With Joanna’s
new role at the Golem Project, she will no longer have time to function as a QST
member. Therefore, Joanna will officially transfer ownership of the Qubes
Master Signing Key (QMSK) (https://www.qubes-os.org/security/verifying-signatures/#1-get-the-qubes-master-signing-key-and-verify-its-authenticity) to Marek, and she will no longer sign QSBs.
However, due to the nature of PGP keys, there is no way to guarantee that Joanna
will not retain a copy of the QMSK after transferring ownership to Marek. Since
anyone in possession of the QMSK is a potential attack vector against the
project, Joanna will continue to sign Qubes Canaries (https://www.qubes-os.org/security/canaries/) in perpetuity.
With Joanna’s departure from the QST, Marek would remain as its sole member.
Given the critical importance of the QST to the project, however, we believe
that a single member would be insufficient. Therefore, after careful
consideration, we have selected a new member for the QST from among our
experienced Qubes Team members: Simon Gaiser (aka HW42) (https://www.qubes-os.org/team/#simon-gaiser-aka-hw42).
About Simon
Simon (https://www.qubes-os.org/team/#simon-gaiser-aka-hw42) has been a member of the Qubes Team for over two years and has been a
contributor to the project since 2014. He has worked on many different parts of
the Qubes codebase, including core, Xen, kernel, and GUI components. Earlier
this year, he joined Invisible Things Lab (ITL) and has been gaining experience
with other security projects. His thorough knowledge of Qubes OS, ability to
assess the severity of security vulnerabilities, and experience preparing Xen
patches make him very well-suited to the QST. Most importantly, both Joanna and
Marek trust him with the responsibilities of this important role. We are pleased
to announce Simon’s new role as a QST member. Congratulations, Simon, and thank
you for working to keep Qubes secure!
https://www.qubes-os.org/news/2018/11/05/qubes-security-team-update/
As we recently announced, Joanna Rutkowska (https://www.qubes-os.org/team/#joanna-rutkowska) has turned over leadership of the
Qubes OS Project to Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki) (see Joanna’s announcement (https://www.qubes-os.org/news/2018/10/25/the-next-chapter/)
and Marek’s announcement (https://www.qubes-os.org/news/2018/10/25/thank-you-joanna/)). In this post, we’ll discuss the implications of
these changes for the Qubes Security Team and how we’re addressing them.
What is the Qubes Security Team?
The Qubes Security Team (QST) (https://www.qubes-os.org/security/#the-qubes-security-team) is the subset of the Qubes Team (https://www.qubes-os.org/team/) that is
responsible for ensuring the security of Qubes OS and the Qubes OS Project.
In particular, the QST is responsible for:
Responding to reported security issues (https://www.qubes-os.org/security/#reporting-security-issues-in-qubes-os)
Evaluating whether Xen Security Advisories (XSAs) (https://www.qubes-os.org/security/xsa/) affect the security of
Qubes OS
Writing, applying, and/or distributing security patches to fix
vulnerabilities in Qubes OS
Writing, signing, and publishing Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
Writing, signing, and publishing Qubes Canaries (https://www.qubes-os.org/security/canaries/)
Generating, safeguarding, and using the project’s PGP keys (https://keys.qubes-os.org/keys/)
As a security-oriented operating system, the QST is fundamentally important to
Qubes, and every Qubes user implicitly trusts the members of the QST by virtue
of the actions listed above.
How does the recent change in leadership affect the QST?
Until now, the two members of the QST have been Joanna and Marek. With Joanna’s
new role at the Golem Project, she will no longer have time to function as a QST
member. Therefore, Joanna will officially transfer ownership of the Qubes
Master Signing Key (QMSK) (https://www.qubes-os.org/security/verifying-signatures/#1-get-the-qubes-master-signing-key-and-verify-its-authenticity) to Marek, and she will no longer sign QSBs.
However, due to the nature of PGP keys, there is no way to guarantee that Joanna
will not retain a copy of the QMSK after transferring ownership to Marek. Since
anyone in possession of the QMSK is a potential attack vector against the
project, Joanna will continue to sign Qubes Canaries (https://www.qubes-os.org/security/canaries/) in perpetuity.
With Joanna’s departure from the QST, Marek would remain as its sole member.
Given the critical importance of the QST to the project, however, we believe
that a single member would be insufficient. Therefore, after careful
consideration, we have selected a new member for the QST from among our
experienced Qubes Team members: Simon Gaiser (aka HW42) (https://www.qubes-os.org/team/#simon-gaiser-aka-hw42).
About Simon
Simon (https://www.qubes-os.org/team/#simon-gaiser-aka-hw42) has been a member of the Qubes Team for over two years and has been a
contributor to the project since 2014. He has worked on many different parts of
the Qubes codebase, including core, Xen, kernel, and GUI components. Earlier
this year, he joined Invisible Things Lab (ITL) and has been gaining experience
with other security projects. His thorough knowledge of Qubes OS, ability to
assess the severity of security vulnerabilities, and experience preparing Xen
patches make him very well-suited to the QST. Most importantly, both Joanna and
Marek trust him with the responsibilities of this important role. We are pleased
to announce Simon’s new role as a QST member. Congratulations, Simon, and thank
you for working to keep Qubes secure!
Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-561
Hi,
To me, it does not seem like Xen is doing all that it can to get more people using it.
you seem to try and not compete with hyper-v or VMware, but openly tell customers that they can move from VMware to XenServer, but not from hyper-v to XenServer.
needed feature:
-built-in VM network micro-segmentation must be part of the core of Xen.
-- you can use simple access list or network list AWS but per VM.
-built-in security guard must be part of the core of Xen.
(Xen does not need add-ons for these features, they need to bake into the core of XEN)
thanks.
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-561
Hi,
To me, it does not seem like Xen is doing all that it can to get more people using it.
you seem to try and not compete with hyper-v or VMware, but openly tell customers that they can move from VMware to XenServer, but not from hyper-v to XenServer.
needed feature:
-built-in VM network micro-segmentation must be part of the core of Xen.
-- you can use simple access list or network list AWS but per VM.
-built-in security guard must be part of the core of Xen.
(Xen does not need add-ons for these features, they need to bake into the core of XEN)
thanks.
Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-562
correction:
"— you can use simple access list or network list, like AWS, but per VM"
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-562
correction:
"— you can use simple access list or network list, like AWS, but per VM"
Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-563
future point 3:
if you can get Xen booted in under 10 seconds, then how about trying to put Xen in server or pc BIOS/UEFI or onboard EPROM.
I am sure you can talk Intel/IBM/AMD to create a new onboard UEFI/BIOS chip that uses 3D-NVDIMM & NVMe, that way the pc/server only has one bios/efi and that is Xen.
thanks.
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-563
future point 3:
if you can get Xen booted in under 10 seconds, then how about trying to put Xen in server or pc BIOS/UEFI or onboard EPROM.
I am sure you can talk Intel/IBM/AMD to create a new onboard UEFI/BIOS chip that uses 3D-NVDIMM & NVMe, that way the pc/server only has one bios/efi and that is Xen.
thanks.
XSA-282 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/11/06/xsa-282-qubes-not-affected/
Dear Qubes Community,
The Xen Project has published Xen Security Advisory 282 (XSA-282). 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/#282
https://www.qubes-os.org/news/2018/11/06/xsa-282-qubes-not-affected/
Dear Qubes Community,
The Xen Project has published Xen Security Advisory 282 (XSA-282). 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/#282
Qubes OS 3.2.1 has been released!
https://www.qubes-os.org/news/2018/11/12/qubes-321/
We’re pleased to announce the stable release of Qubes 3.2.1! As we previously
announced (https://www.qubes-os.org/news/2018/10/05/qubes-321-rc1/), this is the first and only planned point release for
version 3.2. Since no major problems were discovered with 3.2.1-rc1, this stable
release is not significantly different from the release candidate. Features:
Fedora 28 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Release 3.2.1 has replaced Release 3.2 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, 3.2) inclusive of all updates up to a certain point. Installing
Qubes 3.2 and fully updating it results in the same system as installing
Qubes 3.2.1.
What should I do?
If you’re currently using an up-to-date Qubes 3.2 installation, then
your system is already equivalent to a Qubes 3.2.1 installation. No
action is needed.
Regardless of your current OS, if you wish to install (or reinstall)
Qubes 3.2 for any reason, then the 3.2.1 ISO will make this more
convenient and secure, since it bundles all Qubes 3.2 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 3.2 installer.
As a reminder, Qubes 3.2 (and, therefore, Qubes 3.2.1) is scheduled to
reach EOL (end-of-life) on 2019-03-28 (https://www.qubes-os.org/doc/supported-versions/#qubes-os).
What about Qubes 4.0.1?
We recently announced the release of 4.0.1-rc1 (https://www.qubes-os.org/news/2018/11/05/qubes-401-rc1/). You can help us test (https://www.qubes-os.org/doc/testing/) this
release candidate and report any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/) so that they can be fixed
before the stable release.
https://www.qubes-os.org/news/2018/11/12/qubes-321/
We’re pleased to announce the stable release of Qubes 3.2.1! As we previously
announced (https://www.qubes-os.org/news/2018/10/05/qubes-321-rc1/), this is the first and only planned point release for
version 3.2. Since no major problems were discovered with 3.2.1-rc1, this stable
release is not significantly different from the release candidate. Features:
Fedora 28 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Release 3.2.1 has replaced Release 3.2 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, 3.2) inclusive of all updates up to a certain point. Installing
Qubes 3.2 and fully updating it results in the same system as installing
Qubes 3.2.1.
What should I do?
If you’re currently using an up-to-date Qubes 3.2 installation, then
your system is already equivalent to a Qubes 3.2.1 installation. No
action is needed.
Regardless of your current OS, if you wish to install (or reinstall)
Qubes 3.2 for any reason, then the 3.2.1 ISO will make this more
convenient and secure, since it bundles all Qubes 3.2 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 3.2 installer.
As a reminder, Qubes 3.2 (and, therefore, Qubes 3.2.1) is scheduled to
reach EOL (end-of-life) on 2019-03-28 (https://www.qubes-os.org/doc/supported-versions/#qubes-os).
What about Qubes 4.0.1?
We recently announced the release of 4.0.1-rc1 (https://www.qubes-os.org/news/2018/11/05/qubes-401-rc1/). You can help us test (https://www.qubes-os.org/doc/testing/) this
release candidate and report any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/) so that they can be fixed
before the stable release.
Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-565
future point 4:
1) you need to have storage backbone use RDMA & SR-IOV in the core of Xen.
2) you need to look at hyper-converge, make sure the foundation in bake into Xen core, see #1 above.
thanks.
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-565
future point 4:
1) you need to have storage backbone use RDMA & SR-IOV in the core of Xen.
2) you need to look at hyper-converge, make sure the foundation in bake into Xen core, see #1 above.
thanks.
Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-566
future point 5:
1) Support 2 version of Xen:
a. A long-term support option, 5 to 9 years.
b. and An always updated version, 6-12 months.
2) Version numbers by year-month_day
eg: Xen-2018-11_15
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-566
future point 5:
1) Support 2 version of Xen:
a. A long-term support option, 5 to 9 years.
b. and An always updated version, 6-12 months.
2) Version numbers by year-month_day
eg: Xen-2018-11_15
XSA-276, XSA-277, and XSA-279 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/11/19/xsa-276-277-279-qubes-not-affected/
The Xen Project has published Xen Security Advisories 276, 277, and 279
(XSA-276, XSA-277, and XSA-279, 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/#276
https://www.qubes-os.org/security/xsa/#277
https://www.qubes-os.org/security/xsa/#279
https://www.qubes-os.org/news/2018/11/19/xsa-276-277-279-qubes-not-affected/
The Xen Project has published Xen Security Advisories 276, 277, and 279
(XSA-276, XSA-277, and XSA-279, 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/#276
https://www.qubes-os.org/security/xsa/#277
https://www.qubes-os.org/security/xsa/#279
QSB #44: Multiple Xen vulnerabilities (XSA-275, XSA-280)
https://www.qubes-os.org/news/2018/11/20/qsb-44/
We have just published Qubes Security Bulletin (QSB) #44: Multiple Xen
vulnerabilities (XSA-275, XSA-280). 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 #44 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-044-2018.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-275 and XSA-280 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#275
https://www.qubes-os.org/security/xsa/#280
---===[ Qubes Security Bulletin #44 ]===---
2018-11-20
Multiple Xen vulnerabilities (XSA-275, XSA-280)
Summary
========
On 2018-11-20, the Xen Security Team published multiple Xen Security
Advisories (XSAs):
XSA-275 [1] "insufficient TLB flushing / improper large page mappings
with AMD IOMMUs":
| In order to be certain that no undue access to memory is possible
| anymore after IOMMU mappings of this memory have been removed,
| Translation Lookaside Buffers (TLBs) need to be flushed after most
| changes to such mappings. Xen bypassed certain IOMMU flushes on AMD
| x86 hardware.
|
| Furthermore logic exists Xen to re-combine small page mappings
| into larger ones. Such re-combination could have occured in cases
| when it was not really safe/correct to do so.
|
| A malicious or buggy guest may be able to escalate its privileges, may
| cause a Denial of Service (DoS) affecting the entire host, or may be
| able to access data it is not supposed to access (information leak).
XSA-275 affects only AMD CPUs using IOMMU on both Qubes OS 3.2 and Qubes
OS 4.0. XSA-275 does not affect Intel CPUs on any Qubes OS version.
XSA-280 [2] "Fix for XSA-240 conflicts with shadow paging":
| The fix for XSA-240 introduced a new field into the control structure
| associated with each page of RAM. This field was added to a union,
| another member of which is used when Xen uses shadow paging for the
| guest. During migration, or with the L1TF (XSA-273) mitigation for
| PV guests in effect, the two uses conflict.
|
| A malicious or buggy x86 PV guest may cause Xen to crash, resulting in
| a DoS (Denial of Service) affecting the entire host. Privilege
| escalation as well as information leaks cannot be ruled out.
XSA-280 affects only Qubes OS 3.2. XSA-280 does not affect Qubes OS 4.0,
since the shadow paging feature is disabled at build time for 4.0.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes OS 3.2:
- Xen packages, version 4.6.6-45
For Qubes OS 4.0:
- Xen packages, version 4.8.4-7
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
Xen binaries.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-275.html
[2] https://xenbits.xen.org/xsa/advisory-280.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
https://www.qubes-os.org/news/2018/11/20/qsb-44/
We have just published Qubes Security Bulletin (QSB) #44: Multiple Xen
vulnerabilities (XSA-275, XSA-280). 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 #44 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-044-2018.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-275 and XSA-280 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#275
https://www.qubes-os.org/security/xsa/#280
---===[ Qubes Security Bulletin #44 ]===---
2018-11-20
Multiple Xen vulnerabilities (XSA-275, XSA-280)
Summary
========
On 2018-11-20, the Xen Security Team published multiple Xen Security
Advisories (XSAs):
XSA-275 [1] "insufficient TLB flushing / improper large page mappings
with AMD IOMMUs":
| In order to be certain that no undue access to memory is possible
| anymore after IOMMU mappings of this memory have been removed,
| Translation Lookaside Buffers (TLBs) need to be flushed after most
| changes to such mappings. Xen bypassed certain IOMMU flushes on AMD
| x86 hardware.
|
| Furthermore logic exists Xen to re-combine small page mappings
| into larger ones. Such re-combination could have occured in cases
| when it was not really safe/correct to do so.
|
| A malicious or buggy guest may be able to escalate its privileges, may
| cause a Denial of Service (DoS) affecting the entire host, or may be
| able to access data it is not supposed to access (information leak).
XSA-275 affects only AMD CPUs using IOMMU on both Qubes OS 3.2 and Qubes
OS 4.0. XSA-275 does not affect Intel CPUs on any Qubes OS version.
XSA-280 [2] "Fix for XSA-240 conflicts with shadow paging":
| The fix for XSA-240 introduced a new field into the control structure
| associated with each page of RAM. This field was added to a union,
| another member of which is used when Xen uses shadow paging for the
| guest. During migration, or with the L1TF (XSA-273) mitigation for
| PV guests in effect, the two uses conflict.
|
| A malicious or buggy x86 PV guest may cause Xen to crash, resulting in
| a DoS (Denial of Service) affecting the entire host. Privilege
| escalation as well as information leaks cannot be ruled out.
XSA-280 affects only Qubes OS 3.2. XSA-280 does not affect Qubes OS 4.0,
since the shadow paging feature is disabled at build time for 4.0.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes OS 3.2:
- Xen packages, version 4.6.6-45
For Qubes OS 4.0:
- Xen packages, version 4.8.4-7
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
Xen binaries.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-275.html
[2] https://xenbits.xen.org/xsa/advisory-280.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Fedora 27 has reached EOL
https://www.qubes-os.org/news/2018/11/30/fedora-27-eol/
The Fedora Project announced today that Fedora 27 has reached EOL
(end-of-life (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule)). We strongly recommend that all Qubes users upgrade
their Fedora 27 TemplateVMs and StandaloneVMs to Fedora 28 immediately.
We provide step-by-step upgrade instructions for upgrading from Fedora
27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/). For a complete list of TemplateVM versions supported for your
specific version of Qubes, see Supported TemplateVM Versions (https://www.qubes-os.org/doc/supported-versions/#templatevms).
We also provide a fresh Fedora 28 TemplateVM package through the
official Qubes repositories, which you can install in dom0 by following
the standard installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing).
After upgrading your TemplateVMs, please remember to set all qubes that
were using the old template to use the new one. The instructions to do
this can be found in the upgrade instructions for Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our Note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
https://www.qubes-os.org/news/2018/11/30/fedora-27-eol/
The Fedora Project announced today that Fedora 27 has reached EOL
(end-of-life (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule)). We strongly recommend that all Qubes users upgrade
their Fedora 27 TemplateVMs and StandaloneVMs to Fedora 28 immediately.
We provide step-by-step upgrade instructions for upgrading from Fedora
27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/). For a complete list of TemplateVM versions supported for your
specific version of Qubes, see Supported TemplateVM Versions (https://www.qubes-os.org/doc/supported-versions/#templatevms).
We also provide a fresh Fedora 28 TemplateVM package through the
official Qubes repositories, which you can install in dom0 by following
the standard installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing).
After upgrading your TemplateVMs, please remember to set all qubes that
were using the old template to use the new one. The instructions to do
this can be found in the upgrade instructions for Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our Note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
QSB #45: Insecure default Salt configuration
https://www.qubes-os.org/news/2018/12/03/qsb-45/
We have just published Qubes Security Bulletin (QSB) #45: Insecure
default Salt 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 #45 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-045-2018.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 #45 ]===---
2018-12-03
Insecure default Salt configuration
Summary
========
In Qubes OS, one use of Salt (aka SaltStack) is to configure software
installed in domUs (including TemplateVMs and AppVMs). [1] To protect
dom0 from potentially compromised domUs, all complex processing is done
in a DisposableVM. [2] Each target domU being configured gets a separate
DisposableVM, which is given power to execute arbitrary commands
(through the qubes.VMShell qrexec service) in that target domU.
In the default configuration, each DisposableVM generated for this
purpose is based on the same default DVM Template that is used for all
other default DisposableVM actions (including the default "Disposable:
Firefox" menu entry). This DVM Template has a red label and has
networking enabled, which might suggest that it is not
security-critical. However, if this default DVM Template were
compromised (for example, by a web browser plugin the user had installed
there [3]), then the next time Salt were used, it could also compromise
all target domUs it were configuring.
Although it is possible to use an alternative DVM Template for Salt, the
option to do so has not been exposed through any command-line or
graphical user interface.
Vulnerable systems
==================
To exploit this vulnerability, two conditions must be met:
1. The user must actively use Salt to configure software inside a domU.
This does not happen by default; user intervention is required. Only
domUs configured by Salt are affected.
2. The user must compromise the default DVM Template. (For example, the
user might customize the DVM Template by installing an untrusted
program in it, not realizing the security implications of doing so.)
The issue affects only Qubes OS 4.0. In Qubes 3.2, Salt processing
occurs in a temporary AppVM based on the default TemplateVM.
Resolution
==========
To fix this problem, we are implementing two changes:
1. Adding the "management_dispvm" VM property, which specifies the DVM
Template that should be used for management, such as Salt
configuration. TemplateBasedVMs inherit this property from their
parent TemplateVMs. If the value is not set explicitly, the default
is taken from the global "management_dispvm" property. The
VM-specific property is set with the qvm-prefs command, while the
global property is set with the qubes-prefs command.
2. Creating the "default-mgmt-dvm" DVM Template, which is hidden from
the menu (to avoid accidental use), has networking disabled, and has
a black label (the same as TemplateVMs). This VM is set as the global
"management_dispvm".
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.36
- qubes-mgmt-salt-dom0-virtual-machines version 4.0.15
- qubes-mgmt-salt-admin-tools version 4.0.12
For Qubes OS 3.2:
- No packages necessary, since 3.2 is not affected.
(See above for details.)
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
https://www.qubes-os.org/news/2018/12/03/qsb-45/
We have just published Qubes Security Bulletin (QSB) #45: Insecure
default Salt 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 #45 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-045-2018.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 #45 ]===---
2018-12-03
Insecure default Salt configuration
Summary
========
In Qubes OS, one use of Salt (aka SaltStack) is to configure software
installed in domUs (including TemplateVMs and AppVMs). [1] To protect
dom0 from potentially compromised domUs, all complex processing is done
in a DisposableVM. [2] Each target domU being configured gets a separate
DisposableVM, which is given power to execute arbitrary commands
(through the qubes.VMShell qrexec service) in that target domU.
In the default configuration, each DisposableVM generated for this
purpose is based on the same default DVM Template that is used for all
other default DisposableVM actions (including the default "Disposable:
Firefox" menu entry). This DVM Template has a red label and has
networking enabled, which might suggest that it is not
security-critical. However, if this default DVM Template were
compromised (for example, by a web browser plugin the user had installed
there [3]), then the next time Salt were used, it could also compromise
all target domUs it were configuring.
Although it is possible to use an alternative DVM Template for Salt, the
option to do so has not been exposed through any command-line or
graphical user interface.
Vulnerable systems
==================
To exploit this vulnerability, two conditions must be met:
1. The user must actively use Salt to configure software inside a domU.
This does not happen by default; user intervention is required. Only
domUs configured by Salt are affected.
2. The user must compromise the default DVM Template. (For example, the
user might customize the DVM Template by installing an untrusted
program in it, not realizing the security implications of doing so.)
The issue affects only Qubes OS 4.0. In Qubes 3.2, Salt processing
occurs in a temporary AppVM based on the default TemplateVM.
Resolution
==========
To fix this problem, we are implementing two changes:
1. Adding the "management_dispvm" VM property, which specifies the DVM
Template that should be used for management, such as Salt
configuration. TemplateBasedVMs inherit this property from their
parent TemplateVMs. If the value is not set explicitly, the default
is taken from the global "management_dispvm" property. The
VM-specific property is set with the qvm-prefs command, while the
global property is set with the qubes-prefs command.
2. Creating the "default-mgmt-dvm" DVM Template, which is hidden from
the menu (to avoid accidental use), has networking disabled, and has
a black label (the same as TemplateVMs). This VM is set as the global
"management_dispvm".
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.36
- qubes-mgmt-salt-dom0-virtual-machines version 4.0.15
- qubes-mgmt-salt-admin-tools version 4.0.12
For Qubes OS 3.2:
- No packages necessary, since 3.2 is not affected.
(See above for details.)
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 Demi M. Obenour
References
===========
[1] https://www.qubes-os.org/doc/salt/#configuring-a-vms-system-from-dom0
[2] https://github.com/QubesOS/qubes-issues/issues/1541#issuecomment-187482786
[3] https://www.qubes-os.org/doc/dispvm-customization/
--
The Qubes Security Team
https://www.qubes-os.org/security/
$ 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 Demi M. Obenour
References
===========
[1] https://www.qubes-os.org/doc/salt/#configuring-a-vms-system-from-dom0
[2] https://github.com/QubesOS/qubes-issues/issues/1541#issuecomment-187482786
[3] https://www.qubes-os.org/doc/dispvm-customization/
--
The Qubes Security Team
https://www.qubes-os.org/security/
Xen Project 4.11.1 and 4.8.5 are available
https://blog.xenproject.org/2018/12/13/xen-project-4-11-1-and-4-8-5-are-available/
I am pleased to announce the release of Xen 4.11.1 and 4.8.5. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.11 and 4.8 stable series update to the latest point release. These releases are available from their git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.11 (tag RELEASE-4.11.1) xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 […]
https://blog.xenproject.org/2018/12/13/xen-project-4-11-1-and-4-8-5-are-available/
I am pleased to announce the release of Xen 4.11.1 and 4.8.5. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.11 and 4.8 stable series update to the latest point release. These releases are available from their git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.11 (tag RELEASE-4.11.1) xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 […]