RT @rootkovska: Yesterday I discussed the (long-term) vision of @QubesOS running on top of @golemproject decentralized compute cloud, announced cooperation.
RT @julianzawist: I am excited & think this will result in great advancements for both @QubesOS and @golemproject https://t.co/vqal5Hf5hw
Twitter
Joanna Rutkowska
Yesterday I discussed the (long-term) vision of @QubesOS running on top of @golemproject decentralized compute cloud, announced cooperation.
Forwarded from Pavel Durov
If you haven’t read it yet, here’s the full story about the US agencies’ attempts to infiltrate Telegram last year: https://thebaffler.com/salvos/the-crypto-keepers-levine
It tells how the FBI tried to influence me and bribe our engineer in May 2016 to make Telegram less secure. Luckily, since neither of us are US citizens, we could afford to refuse their offers and I was able to tell the public about these attempts. If we were American citizens, the FBI would have likely tried to silence us using a legal procedure called a "gag order" – when the US authorities can not only demand that you do something (like plant a backdoor into your app), but also prohibit you from telling the public about it (otherwise you can end up in jail).
That whole story made me ask myself this question: if our team experienced such pressure during just one week’s trip to America, what kind of pressure are US-based tech companies facing every day? How can a privacy oriented company permanently operate from America? We can hope that the open US legal system would defend them, but due to the secrecy of these “gag orders” we would never even know if things went wrong. And unfortunately, Edward Snowden’s revelations confirm some of the worst fears.
The article also provides facts that confirm something that I always feared could be true – that some of the famous and most vocal US-based influencers within the cryptography world are sponsored by the US government to push the agenda of its agencies. Some past cases are widely known (like NSA infiltrating RSA), but it looks like the level of collaboration between US agencies and these influential “privacy advocates” is much deeper.
All of this makes protecting privacy really hard, particularly considering the fact that Google and Apple – the two companies which we are dependent on for mobile operating systems – are based in the US. I don't see any easy recipe or solution to fix this. I wish one day huge companies like Apple and Google can become independent of any government that can distort the mission of their founders (maybe start their own countries?).
Until then, I’ll continue doing my part building Telegram and protecting our users, even if that will require speaking out under gag orders. I know this can probably get me into trouble some day, as it did in the past when I was living in Russia. But this is the only way I can imagine myself going forward, so I don't have and won’t have any regrets. It’s all worth it because of you guys – the millions of users who entrusted their private data to Telegram.
It tells how the FBI tried to influence me and bribe our engineer in May 2016 to make Telegram less secure. Luckily, since neither of us are US citizens, we could afford to refuse their offers and I was able to tell the public about these attempts. If we were American citizens, the FBI would have likely tried to silence us using a legal procedure called a "gag order" – when the US authorities can not only demand that you do something (like plant a backdoor into your app), but also prohibit you from telling the public about it (otherwise you can end up in jail).
That whole story made me ask myself this question: if our team experienced such pressure during just one week’s trip to America, what kind of pressure are US-based tech companies facing every day? How can a privacy oriented company permanently operate from America? We can hope that the open US legal system would defend them, but due to the secrecy of these “gag orders” we would never even know if things went wrong. And unfortunately, Edward Snowden’s revelations confirm some of the worst fears.
The article also provides facts that confirm something that I always feared could be true – that some of the famous and most vocal US-based influencers within the cryptography world are sponsored by the US government to push the agenda of its agencies. Some past cases are widely known (like NSA infiltrating RSA), but it looks like the level of collaboration between US agencies and these influential “privacy advocates” is much deeper.
All of this makes protecting privacy really hard, particularly considering the fact that Google and Apple – the two companies which we are dependent on for mobile operating systems – are based in the US. I don't see any easy recipe or solution to fix this. I wish one day huge companies like Apple and Google can become independent of any government that can distort the mission of their founders (maybe start their own countries?).
Until then, I’ll continue doing my part building Telegram and protecting our users, even if that will require speaking out under gag orders. I know this can probably get me into trouble some day, as it did in the past when I was living in Russia. But this is the only way I can imagine myself going forward, so I don't have and won’t have any regrets. It’s all worth it because of you guys – the millions of users who entrusted their private data to Telegram.
The Baffler
The Crypto- Keepers
If apps like Signal really posed a threat to the NSA’s surveillance power, why would the U.S. government continue to fund them?
RT @golemproject: Video report & @julianzawist's blogpost on Berlin https://t.co/w366VGaRdC #Ethereum #TrueCloud #Cooperation @omise_go @QubesOS @streamrinc
The Golem Project
After Berlin — the Spirit of Cooperation
We hope you enjoyed Golem’s meetup in Berlin as much as we did. Reflecting on it over the weekend, the team thought it was a great event…
QSB #33: Xen hypervisor (XSA-231 through XSA-234)
https://www.qubes-os.org/news/2017/09/12/qsb-33/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #33:
Xen hypervisor (XSA-231 through XSA-234).
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 #33 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-033-2017.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-231 through XSA-234 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin #33 ]===---
September 12, 2017
Xen hypervisor (XSA-231 through XSA-234)
Summary
========
The Xen Security Team released several Xen Security Advisories today
(XSA-231 through XSA-234). The impact of these advisories ranges from
system crashes to privilege escalations. See our commentary below for
details.
Technical details
==================
Xen Security Advisory 231 [1]:
| The function `alloc_heap_pages` allows callers to specify the first
| NUMA node that should be used for allocations through the `memflags`
| parameter; the node is extracted using the `MEMF_get_node` macro.
|
| While the function checks to see if the special constant
| `NUMA_NO_NODE` is specified, it otherwise does not handle the case
| where `node >= MAX_NUMNODES`. This allows an out-of-bounds access
| to an internal array.
|
| An attacker using crafted hypercalls can execute arbitrary code within
| Xen.
Xen Security Advisory 232 [2]:
| The function `__gnttab_cache_flush` handles GNTTABOP_cache_flush grant
| table operations. It checks to see if the calling domain is the owner
| of the page that is to be operated on. If it is not, the owner's grant
| table is checked to see if a grant mapping to the calling domain
| exists for the page in question.
|
| However, the function does not check to see if the owning domain
| actually has a grant table or not. Some special domains, such as
| `DOMID_XEN`, `DOMID_IO` and `DOMID_COW` are created without grant
| tables. Hence, if __gnttab_cache_flush operates on a page owned by
| these special domains, it will attempt to dereference a null pointer
| in the domain struct.
|
| The guest can get Xen to dereference a NULL pointer.
|
| For ARM guests, and x86 HVM guests, and x86 PV guests on systems with
| SMAP enabled, this will cause a host crash (denial-of-service).
|
| For x86 PV guests on systems without SMAP enabled, an attacker can map
| a crafted grant structure at virtual address 0. This can be leveraged
| to increment an arbitrary virtual address, which can then probably be
| leveraged into a full privilege escalation.
Xen Security Advisory 234 [4]:
| When removing or replacing a grant mapping, the x86 PV specific path
| needs to make sure page table entries remain in sync with other
| accounting done. Although the identity of the page frame was
| validated correctly, neither the presence of the mapping nor page
| writability were taken into account.
|
| A malicious or buggy x86 PV guest could escalate its privileges or
| crash the hypervisor.
The Xen Security Team also released Xen Security Advisory 233 [3], with
only DoS impact:
| When shutting down a VM with a stubdomain, a race in cxenstored may
| cause a double-free.
|
| The xenstored daemon may crash, resulting in a DoS of any parts of the
| system relying on it (including domain creation / destruction,
| ballooning, device changes, etc).
Commentary from the Qubes Security Team
========================================
This batch of Xen security advisories reassures us in our decision to
abandon default para-virtualization (PV) in Qubes 4.0. Indeed, only
https://www.qubes-os.org/news/2017/09/12/qsb-33/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #33:
Xen hypervisor (XSA-231 through XSA-234).
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 #33 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-033-2017.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-231 through XSA-234 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin #33 ]===---
September 12, 2017
Xen hypervisor (XSA-231 through XSA-234)
Summary
========
The Xen Security Team released several Xen Security Advisories today
(XSA-231 through XSA-234). The impact of these advisories ranges from
system crashes to privilege escalations. See our commentary below for
details.
Technical details
==================
Xen Security Advisory 231 [1]:
| The function `alloc_heap_pages` allows callers to specify the first
| NUMA node that should be used for allocations through the `memflags`
| parameter; the node is extracted using the `MEMF_get_node` macro.
|
| While the function checks to see if the special constant
| `NUMA_NO_NODE` is specified, it otherwise does not handle the case
| where `node >= MAX_NUMNODES`. This allows an out-of-bounds access
| to an internal array.
|
| An attacker using crafted hypercalls can execute arbitrary code within
| Xen.
Xen Security Advisory 232 [2]:
| The function `__gnttab_cache_flush` handles GNTTABOP_cache_flush grant
| table operations. It checks to see if the calling domain is the owner
| of the page that is to be operated on. If it is not, the owner's grant
| table is checked to see if a grant mapping to the calling domain
| exists for the page in question.
|
| However, the function does not check to see if the owning domain
| actually has a grant table or not. Some special domains, such as
| `DOMID_XEN`, `DOMID_IO` and `DOMID_COW` are created without grant
| tables. Hence, if __gnttab_cache_flush operates on a page owned by
| these special domains, it will attempt to dereference a null pointer
| in the domain struct.
|
| The guest can get Xen to dereference a NULL pointer.
|
| For ARM guests, and x86 HVM guests, and x86 PV guests on systems with
| SMAP enabled, this will cause a host crash (denial-of-service).
|
| For x86 PV guests on systems without SMAP enabled, an attacker can map
| a crafted grant structure at virtual address 0. This can be leveraged
| to increment an arbitrary virtual address, which can then probably be
| leveraged into a full privilege escalation.
Xen Security Advisory 234 [4]:
| When removing or replacing a grant mapping, the x86 PV specific path
| needs to make sure page table entries remain in sync with other
| accounting done. Although the identity of the page frame was
| validated correctly, neither the presence of the mapping nor page
| writability were taken into account.
|
| A malicious or buggy x86 PV guest could escalate its privileges or
| crash the hypervisor.
The Xen Security Team also released Xen Security Advisory 233 [3], with
only DoS impact:
| When shutting down a VM with a stubdomain, a race in cxenstored may
| cause a double-free.
|
| The xenstored daemon may crash, resulting in a DoS of any parts of the
| system relying on it (including domain creation / destruction,
| ballooning, device changes, etc).
Commentary from the Qubes Security Team
========================================
This batch of Xen security advisories reassures us in our decision to
abandon default para-virtualization (PV) in Qubes 4.0. Indeed, only
one of the potential privilege-escalation bugs discussed in this
advisory affects non-PV virtualization: XSA-231. This bug is a prime
example of the common problems associated with expanding the codebase
in order to implement "exotic" functionality (in this case, NUMA
support). While the Xen Project has made some progress recently in
allowing extra features to be disabled at compile time, the code for
NUMA support could not easily be deactivated, which is the reason for
the inclusion of this bug in today's advisory.
While the departure from para-virtualization (PV) in Qubes 4.0 will
obviate many such vulnerabilities in the future, please note that
Qubes 3.2 (the current, stable version of Qubes) still uses PV mode
for most of the VMs. Therefore, all the bugs in this bulletin affect
Qubes 3.2, and users should patch immediately.
Compromise Recovery
====================
Starting with Qubes 3.2, we offer Paranoid Backup Restore Mode, which
was designed specifically to aid in the recovery of a (potentially)
compromised Qubes OS system. Thus, if you believe your system might have
been compromised (perhaps because of the bugs discussed in this
bulletin), then you should read and follow the procedure described here:
https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-30
For Qubes 4.0:
- Xen packages, version 4.8.2-2
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 Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-231.html
[2] https://xenbits.xen.org/xsa/advisory-232.html
[3] https://xenbits.xen.org/xsa/advisory-233.html
[4] https://xenbits.xen.org/xsa/advisory-234.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
advisory affects non-PV virtualization: XSA-231. This bug is a prime
example of the common problems associated with expanding the codebase
in order to implement "exotic" functionality (in this case, NUMA
support). While the Xen Project has made some progress recently in
allowing extra features to be disabled at compile time, the code for
NUMA support could not easily be deactivated, which is the reason for
the inclusion of this bug in today's advisory.
While the departure from para-virtualization (PV) in Qubes 4.0 will
obviate many such vulnerabilities in the future, please note that
Qubes 3.2 (the current, stable version of Qubes) still uses PV mode
for most of the VMs. Therefore, all the bugs in this bulletin affect
Qubes 3.2, and users should patch immediately.
Compromise Recovery
====================
Starting with Qubes 3.2, we offer Paranoid Backup Restore Mode, which
was designed specifically to aid in the recovery of a (potentially)
compromised Qubes OS system. Thus, if you believe your system might have
been compromised (perhaps because of the bugs discussed in this
bulletin), then you should read and follow the procedure described here:
https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-30
For Qubes 4.0:
- Xen packages, version 4.8.2-2
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 Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-231.html
[2] https://xenbits.xen.org/xsa/advisory-232.html
[3] https://xenbits.xen.org/xsa/advisory-233.html
[4] https://xenbits.xen.org/xsa/advisory-234.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Joanna Rutkowska: Reasonably Secure Computing in the Decentralized World
https://www.qubes-os.org/news/2017/09/13/joanna-rutkowska-secure-computing-decentralized-world/
Joanna Rutkowska (https://www.qubes-os.org/team/#joanna-rutkowska) recently gave a presentation noscriptd
“Reasonably Secure Computing in the Decentralized World (An Operating System
Architect’s Perspective)” at a public event hosted by
The Golem Project (https://golem.network/) in Berlin, Germany
called “Golem and Friends: Data, Security, Scaling and More….”
The slides from her presentation are available
here (https://www.qubes-os.org/attachment/wiki/slides/Secure_Computing_in_Decentralized_World.pdf).
The event was streamed live, and the video is available
here (https://www.youtube.com/watch?v=B1QCm09BvP4&feature=youtu.be&t=31m52s).
https://www.qubes-os.org/news/2017/09/13/joanna-rutkowska-secure-computing-decentralized-world/
Joanna Rutkowska (https://www.qubes-os.org/team/#joanna-rutkowska) recently gave a presentation noscriptd
“Reasonably Secure Computing in the Decentralized World (An Operating System
Architect’s Perspective)” at a public event hosted by
The Golem Project (https://golem.network/) in Berlin, Germany
called “Golem and Friends: Data, Security, Scaling and More….”
The slides from her presentation are available
here (https://www.qubes-os.org/attachment/wiki/slides/Secure_Computing_in_Decentralized_World.pdf).
The event was streamed live, and the video is available
here (https://www.youtube.com/watch?v=B1QCm09BvP4&feature=youtu.be&t=31m52s).
Thank You for Supporting Qubes!
https://www.qubes-os.org/news/2017/09/15/thank-you-for-supporting-qubes/
Dear Qubes Community,
When we reflect on how the Qubes userbase has grown (https://www.qubes-os.org/statistics/) over
the past few years, we are humbled by the number of people who have
chosen to join us in entrusting the security of their digital lives to
Qubes. We recognize the immense responsibility this places on us. This
sense of duty is what drives our work to make Qubes as secure as it can
be.
We are further humbled by the many generous donations that have been
made this year. Qubes is protecting real people around the world in ever
greater numbers, and many of you have shown your appreciation by giving
back to the project. We are truly grateful for your support. Thank you.
Top Donors of 2017
We’d like to take this opportunity to thank the top donors of 2017 (so
far!):
50,000 EUR from Mullvad!
10 BTC from an anonymous donor!
10,000 USD from zby, angel investor!
1,000 USD recurring annual donation from Eric Grosse!
Thank you to these donors and to everyone who has donated to the Qubes
Decentralized Bitcoin Fund (https://www.qubes-os.org/news/2016/07/13/qubes-distributed-fund/) and the Qubes Open Collective (https://opencollective.com/qubes-os)!
Your donations continue to fund work on Qubes OS. Thanks to your
support, we’ve just released Qubes 4.0-rc1 (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/), and we’re getting
ever closer to a stable release!
Our Work Continues
Today, Qubes safeguards tens of thousands of users around the globe in
their work and personal lives, including every member of the Qubes Team.
But the path here has been a long and difficult one, in terms of both
the great dedication required of the team and the monetary costs that
Invisible Things Lab has borne, and continues to bear, so that the
project could continue throughout the years.
Without a doubt, it’s all been worth it. Qubes is our passion. It’s part
of our lives. We’re gratified and exhilarated to see Qubes bringing real
value to people around the world, and we’re more determined than ever to
make Qubes the best free and open-source secure operating system it can
be – for everyone. We know that many of you feel the same way we do.
If Qubes is important to you, please consider joining us in supporting
its ongoing development (https://www.qubes-os.org/donate/). Everyone’s support is valuable to
us, no matter how large or how small. Together, we can ensure that Qubes
is around to protect us all for a long time to come.
Sincerely,
The Qubes OS Team
https://www.qubes-os.org/news/2017/09/15/thank-you-for-supporting-qubes/
Dear Qubes Community,
When we reflect on how the Qubes userbase has grown (https://www.qubes-os.org/statistics/) over
the past few years, we are humbled by the number of people who have
chosen to join us in entrusting the security of their digital lives to
Qubes. We recognize the immense responsibility this places on us. This
sense of duty is what drives our work to make Qubes as secure as it can
be.
We are further humbled by the many generous donations that have been
made this year. Qubes is protecting real people around the world in ever
greater numbers, and many of you have shown your appreciation by giving
back to the project. We are truly grateful for your support. Thank you.
Top Donors of 2017
We’d like to take this opportunity to thank the top donors of 2017 (so
far!):
50,000 EUR from Mullvad!
10 BTC from an anonymous donor!
10,000 USD from zby, angel investor!
1,000 USD recurring annual donation from Eric Grosse!
Thank you to these donors and to everyone who has donated to the Qubes
Decentralized Bitcoin Fund (https://www.qubes-os.org/news/2016/07/13/qubes-distributed-fund/) and the Qubes Open Collective (https://opencollective.com/qubes-os)!
Your donations continue to fund work on Qubes OS. Thanks to your
support, we’ve just released Qubes 4.0-rc1 (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/), and we’re getting
ever closer to a stable release!
Our Work Continues
Today, Qubes safeguards tens of thousands of users around the globe in
their work and personal lives, including every member of the Qubes Team.
But the path here has been a long and difficult one, in terms of both
the great dedication required of the team and the monetary costs that
Invisible Things Lab has borne, and continues to bear, so that the
project could continue throughout the years.
Without a doubt, it’s all been worth it. Qubes is our passion. It’s part
of our lives. We’re gratified and exhilarated to see Qubes bringing real
value to people around the world, and we’re more determined than ever to
make Qubes the best free and open-source secure operating system it can
be – for everyone. We know that many of you feel the same way we do.
If Qubes is important to you, please consider joining us in supporting
its ongoing development (https://www.qubes-os.org/donate/). Everyone’s support is valuable to
us, no matter how large or how small. Together, we can ensure that Qubes
is around to protect us all for a long time to come.
Sincerely,
The Qubes OS Team
RT @andrewdavidwong: On behalf of our entire team:
Thank you for supporting Qubes!
https://t.co/tmtjvmfOJr
Thank you for supporting Qubes!
https://t.co/tmtjvmfOJr
Qubes OS
Qubes OS is a security-oriented, open-source operating system for personal computers. It uses virtualization to implement security by compartmentalization and supports both Linux and Windows virtual environments.
RT @mullvadnet: We hope our donation to @QubesOS will inspire others to support this vital #itsec project. https://t.co/SG9PgTAFTg #security #opensource
mullvad.net
Mullvad
Mullvad is a VPN service that helps keep your online activity, identity and location private. Only €5/month. We accept Bitcoin, cash, bank wire, credit card (PayPal), and Swish
XSA-245 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2017/09/28/xsa-245/
The Xen Project has published Xen Security Advisory 245 (XSA-245).
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/#245
https://www.qubes-os.org/news/2017/09/28/xsa-245/
The Xen Project has published Xen Security Advisory 245 (XSA-245).
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/#245
RT @kennwhite: Periodic shout out to @rootkovska and the @QubesOS team for *years* of hard work to improve desktop security. Qubes is the real deal.
RT @rootkovska: New post: "Introducing the Next Generation Qubes Core Stack", a practical intro to Qubes 4.0 for power users:
https://t.co/…
https://t.co/…
Introducing the Next Generation Qubes Core Stack
https://www.qubes-os.org/news/2017/10/03/core3/
This is the 2nd post from the “cool things coming in Qubes 4.0” series, and it
discusses the next generation Qubes Core Stack version 3, which is the heart of
the new Qubes 4.x releases. The previous part (https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/) discussed the
Admin API which we also introduced in Qubes 4.0 and which heavily relies on this
new Qubes Core Stack.
Qubes Core Stack vs. Qubes OS
Qubes Core Stack is, as the name implies, the core component of Qubes OS. It’s
the glue that connects all the other components together, and which allows users
and admins to interact with and configure the system. For the record, the other
components of the Qubes system include:
VM-located core agents (implementing e.g. qrexec endpoints used by various
Qubes services),
VM-customizations (making the VMs lightweight and working well with seamless
GUI virtualization),
Qubes GUI virtualization (the protocol, VM-located agents, and daemons
located in the GUI domain which, for now, happens to be the same as dom0),
GUI domain customizations (Desktop Environment customizations, decoration
coloring plugin, etc),
The AdminVM distribution (various customizations, special services, such as
for receiving and verifying updates, in the future: custom distro),
The Xen hypervisor (with a bunch of customization patches, occasional
hardening) or - in the future - some other virtualising or containerizing
software or technology,
Multiple “Qubes Apps” (various services built on top of Qubes qrexec
infrastructure, such as: trusted PDF and Image converters, Split GPG, safe
USB proxies for HID devices, USB proxy for offering USB devices (exposed via
qvm-usb), Yubikey support, USB Armory support, etc)
Various ready-to-use templates (e.g. Debian-, Whonix-based), which are used
to create actual VMs, i.e. provide the root filesystem to the VMs,
Salt Stack integration
And all these components are “glued together” by the Qubes Core Stack. The
diagram below illustrates the location of all these components in the overall
system architecture. Unlike many other Qubes architecture diagrams, this one
takes an AppVM-centric approach. (Click the image for the full size version.)
https://www.qubes-os.org/news/2017/10/03/core3/
This is the 2nd post from the “cool things coming in Qubes 4.0” series, and it
discusses the next generation Qubes Core Stack version 3, which is the heart of
the new Qubes 4.x releases. The previous part (https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/) discussed the
Admin API which we also introduced in Qubes 4.0 and which heavily relies on this
new Qubes Core Stack.
Qubes Core Stack vs. Qubes OS
Qubes Core Stack is, as the name implies, the core component of Qubes OS. It’s
the glue that connects all the other components together, and which allows users
and admins to interact with and configure the system. For the record, the other
components of the Qubes system include:
VM-located core agents (implementing e.g. qrexec endpoints used by various
Qubes services),
VM-customizations (making the VMs lightweight and working well with seamless
GUI virtualization),
Qubes GUI virtualization (the protocol, VM-located agents, and daemons
located in the GUI domain which, for now, happens to be the same as dom0),
GUI domain customizations (Desktop Environment customizations, decoration
coloring plugin, etc),
The AdminVM distribution (various customizations, special services, such as
for receiving and verifying updates, in the future: custom distro),
The Xen hypervisor (with a bunch of customization patches, occasional
hardening) or - in the future - some other virtualising or containerizing
software or technology,
Multiple “Qubes Apps” (various services built on top of Qubes qrexec
infrastructure, such as: trusted PDF and Image converters, Split GPG, safe
USB proxies for HID devices, USB proxy for offering USB devices (exposed via
qvm-usb), Yubikey support, USB Armory support, etc)
Various ready-to-use templates (e.g. Debian-, Whonix-based), which are used
to create actual VMs, i.e. provide the root filesystem to the VMs,
Salt Stack integration
And all these components are “glued together” by the Qubes Core Stack. The
diagram below illustrates the location of all these components in the overall
system architecture. Unlike many other Qubes architecture diagrams, this one
takes an AppVM-centric approach. (Click the image for the full size version.)
There are also a bunch of additional components not shown on the diagram above,
and which technically are not part of a Qubes system, but which are instrumental
in building of the system:
qubes-builder,
template-builder,
tons of automatic tests,
as well as all the supporting infrastructure for building, testing and
distributing Qubes and the updates, and hosting of the website and
documentation.
As you can see Qubes is a pretty complex creature, and the Qubes Core Stack is
central to its existence.
Qubes VMs: the building blocks for Explicit Partitioning Model
Qubes implements explicit partitioning security model, which means that users
(and/or admins) can define multiple security domains and decide what these
domains can and cannot do. This is a different model than the popular sandboxing
model, as implemented by increasingly many applications and products today,
where every application is automatically sandboxed and some more-or-less
pre-defined set of rules is used to prevent behaviour considered “unsafe”
(whatever that might mean…). I believe the explicit partitioning model
provides many benefits over the sandboxing model, among the most important one
being that it is information-oriented, rather than application-oriented. In
other words it tries to limit damage to the (user’s) data, rather to the
(vendor’s) code and infrastructure.
There have always been a few different kinds of VMs in Qubes: AppVMs, Template
VMs, Standalone VMs, NetVMs, ProxyVMs, DispVM, etc. In Qubes 4 we have slightly
simplified and cleaned up these categories.
First we’ve hidden the PV vs HVM distinction. Now each VM has a property named
virt_mode which is used to decide whether it should be virtualized using Xen
para-virtualization (PV), full virtualization with auxiliary qemu in isolated
“stub domain” (HVM), or – in the near future – as full virtualization
without qemu and the additional stub domain (PVH). This means we no longer
classify VMs as PV vs HVMs, because every VM can be easily switched between
various modes of virtualization with a flip of a property.
We also no longer distinguish between AppVMs, NetVMs and Proxy VMs. Instead,
each VM has a property provides_network, which is false by default, except for
the VMs which we want to expose networking to other VMs (e.g. because they might
have some networking device assigned, such as cellular modem or WiFi device, or
because they act as VPNs or proxies of some sort).
We discuss what the properties are and how to check/set them, later in this
article.
So, to recap, starting with Qubes 4.0 we have only the following classes of VMs:
AppVM - covers what we called AppVMs, NetVMs, and ProxyVMs in earlier Qubes
releases,
DispVM - defined by not having a persistent private image across VM
reboots (see also below),
TemplateVM - these provide root filesystem for AppVMs, the semantics
haven’t changed in Qubes 4,
StandaloneVM - these are like AppVMs, but are not based on any
TemplateVM,
AdminVM a singleton (i.e. a class which has only one instance), which
represents the Administrator VM (Up until recently called dom0, a term
we’re departing from, given it is Xen-specific).
One can list all the VM classes known to the stack using the following command:
[user@dom0 ~]$ qvm-create --help-classes
BTW, we’ve been recently promoting the use of alternative names to “VM(s)”, such
as domain(s), and - more recently - “qube(s)”. This is to stress the connection
between Qubes and virtualization technology is less tight that many might
perceive. Another reason is that, we believe, for many users these alternative
terms might be more friendly than “VMs”, which apparently have strong technical
connotation. The author is quite used to the term VM, however, so should be
excused for (ab)using this term throughout her writings.
Properties, Features and Tags
Each VM (domain) in Qubes can have a number of properties, features and tags,
and which technically are not part of a Qubes system, but which are instrumental
in building of the system:
qubes-builder,
template-builder,
tons of automatic tests,
as well as all the supporting infrastructure for building, testing and
distributing Qubes and the updates, and hosting of the website and
documentation.
As you can see Qubes is a pretty complex creature, and the Qubes Core Stack is
central to its existence.
Qubes VMs: the building blocks for Explicit Partitioning Model
Qubes implements explicit partitioning security model, which means that users
(and/or admins) can define multiple security domains and decide what these
domains can and cannot do. This is a different model than the popular sandboxing
model, as implemented by increasingly many applications and products today,
where every application is automatically sandboxed and some more-or-less
pre-defined set of rules is used to prevent behaviour considered “unsafe”
(whatever that might mean…). I believe the explicit partitioning model
provides many benefits over the sandboxing model, among the most important one
being that it is information-oriented, rather than application-oriented. In
other words it tries to limit damage to the (user’s) data, rather to the
(vendor’s) code and infrastructure.
There have always been a few different kinds of VMs in Qubes: AppVMs, Template
VMs, Standalone VMs, NetVMs, ProxyVMs, DispVM, etc. In Qubes 4 we have slightly
simplified and cleaned up these categories.
First we’ve hidden the PV vs HVM distinction. Now each VM has a property named
virt_mode which is used to decide whether it should be virtualized using Xen
para-virtualization (PV), full virtualization with auxiliary qemu in isolated
“stub domain” (HVM), or – in the near future – as full virtualization
without qemu and the additional stub domain (PVH). This means we no longer
classify VMs as PV vs HVMs, because every VM can be easily switched between
various modes of virtualization with a flip of a property.
We also no longer distinguish between AppVMs, NetVMs and Proxy VMs. Instead,
each VM has a property provides_network, which is false by default, except for
the VMs which we want to expose networking to other VMs (e.g. because they might
have some networking device assigned, such as cellular modem or WiFi device, or
because they act as VPNs or proxies of some sort).
We discuss what the properties are and how to check/set them, later in this
article.
So, to recap, starting with Qubes 4.0 we have only the following classes of VMs:
AppVM - covers what we called AppVMs, NetVMs, and ProxyVMs in earlier Qubes
releases,
DispVM - defined by not having a persistent private image across VM
reboots (see also below),
TemplateVM - these provide root filesystem for AppVMs, the semantics
haven’t changed in Qubes 4,
StandaloneVM - these are like AppVMs, but are not based on any
TemplateVM,
AdminVM a singleton (i.e. a class which has only one instance), which
represents the Administrator VM (Up until recently called dom0, a term
we’re departing from, given it is Xen-specific).
One can list all the VM classes known to the stack using the following command:
[user@dom0 ~]$ qvm-create --help-classes
BTW, we’ve been recently promoting the use of alternative names to “VM(s)”, such
as domain(s), and - more recently - “qube(s)”. This is to stress the connection
between Qubes and virtualization technology is less tight that many might
perceive. Another reason is that, we believe, for many users these alternative
terms might be more friendly than “VMs”, which apparently have strong technical
connotation. The author is quite used to the term VM, however, so should be
excused for (ab)using this term throughout her writings.
Properties, Features and Tags
Each VM (domain) in Qubes can have a number of properties, features and tags,
which describe both how it should behave, as well as what features or services
it offers to other VMs:
Properties, as the name suggests, are used to change the behaviour of the
VM and/or how it is treated by the Qubes Core Stack. The virt_mode property
mentioned above is a good example. For a list of other properties, take a
look here (https://dev.qubes-os.org/projects/core-admin/en/latest/qubes.html#properties). A command which can be used to list, read and
set properties for a VM is qvm-prefs (see below).
Features are very similar to properties, except that they are mostly
opaque to the Core (unlike properties, which are well defined and sanitized).
Features are essentially a dictionary of ‘key=value’ pairs assigned to each
VM. They can be used in various places outside of the main logic of the Core
Stack, specifically in Core Extensions (https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-ext.html). A new tool in
Qubes 4 used to inspect or set features is called qvm-features.
A good example of a mechanism implemented on top of features are
services, which have been reimplemented in Qubes 4. Services are used to
let the VM agents know about whether various additional services, such as
Network Manager, should be enabled or not. Indeed, the qvm-service tool now
(i.e. in Qubes 4.0) internally simply creates features named service.XYZ,
where XYZ is the name of the service passed to qvm-service. It also takes
care of interpreting the true/false values.
Finally, each VM can also have some tags associated with it. Unlike
features, tags do not have a value – a VM can either have a specific tag
(“can be tagged with it”) or not. Unlike properties, they are not interpreted
by any core logic of the Core Stack. The sole purpose of tags is that they
can be used for qrexec policy rules, as discussed below. (This is also the
reason why we wanted to keep them absolutely simple – any complexity within
qrexec policy parsing code would definitely be asking for troubles…).
Last but not least, we should mention that each of the VM has a unique
name associated with it. VM names in Qubes are like filenames in the
filesystem – not only they are unique, but they also are used as a primary
way of identifying VMs, especially for security-related decisions (e.g. for
qrexec policy construction, see below).
And just as one can get away with using generic tagging schemes in place of
referring to paths and filenames in some security systems, similarly in Qubes OS
one can refer to tags (mentioned above and discussed later) in the policy
(but currently not in firewalling rules).
Internally, a VM’s name is implemented as the property
name and thus can be read using qvm-prefs. It cannot be changed, however,
because, starting with Qubes 4.0, we treat it as an immutable property.
User-exposed tools, however, do have a “VM rename” operation, which is
implemented as creating a copy of the VM with the new name and removing the old
VM. Thanks to the new volume
manager we also introduced in Qubes 4 (and which will be the topic of another
post), this operation is actually very cheap, disk-wise.
So, let us now start a console in AdminVM (dom0) and play a bit with these
mechanisms.
Let’s start with something very simple and let us take a look at the properties
of the AdminVM (in the current Qubes implemented by Xen’s dom0):
[user@dom0 ~]$ qvm-prefs dom0
default_dispvm D fedora-25-dvm
label - black
name D dom0
qid D 0
uuid D 00000000-0000-0000-0000-000000000000
As we can see, there aren’t many properties for the AdminVM, and none of them
can be modified by the user or admin. While we’re here, we should mention there
exists a similar tool, qubes-prefs which allows one to view and modify the
global system properties, and these properties should not be confused with
the properties of the AdminVM:
[user@dom0 ~]$ qubes-prefs
check_updates_vm D True
it offers to other VMs:
Properties, as the name suggests, are used to change the behaviour of the
VM and/or how it is treated by the Qubes Core Stack. The virt_mode property
mentioned above is a good example. For a list of other properties, take a
look here (https://dev.qubes-os.org/projects/core-admin/en/latest/qubes.html#properties). A command which can be used to list, read and
set properties for a VM is qvm-prefs (see below).
Features are very similar to properties, except that they are mostly
opaque to the Core (unlike properties, which are well defined and sanitized).
Features are essentially a dictionary of ‘key=value’ pairs assigned to each
VM. They can be used in various places outside of the main logic of the Core
Stack, specifically in Core Extensions (https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-ext.html). A new tool in
Qubes 4 used to inspect or set features is called qvm-features.
A good example of a mechanism implemented on top of features are
services, which have been reimplemented in Qubes 4. Services are used to
let the VM agents know about whether various additional services, such as
Network Manager, should be enabled or not. Indeed, the qvm-service tool now
(i.e. in Qubes 4.0) internally simply creates features named service.XYZ,
where XYZ is the name of the service passed to qvm-service. It also takes
care of interpreting the true/false values.
Finally, each VM can also have some tags associated with it. Unlike
features, tags do not have a value – a VM can either have a specific tag
(“can be tagged with it”) or not. Unlike properties, they are not interpreted
by any core logic of the Core Stack. The sole purpose of tags is that they
can be used for qrexec policy rules, as discussed below. (This is also the
reason why we wanted to keep them absolutely simple – any complexity within
qrexec policy parsing code would definitely be asking for troubles…).
Last but not least, we should mention that each of the VM has a unique
name associated with it. VM names in Qubes are like filenames in the
filesystem – not only they are unique, but they also are used as a primary
way of identifying VMs, especially for security-related decisions (e.g. for
qrexec policy construction, see below).
And just as one can get away with using generic tagging schemes in place of
referring to paths and filenames in some security systems, similarly in Qubes OS
one can refer to tags (mentioned above and discussed later) in the policy
(but currently not in firewalling rules).
Internally, a VM’s name is implemented as the property
name and thus can be read using qvm-prefs. It cannot be changed, however,
because, starting with Qubes 4.0, we treat it as an immutable property.
User-exposed tools, however, do have a “VM rename” operation, which is
implemented as creating a copy of the VM with the new name and removing the old
VM. Thanks to the new volume
manager we also introduced in Qubes 4 (and which will be the topic of another
post), this operation is actually very cheap, disk-wise.
So, let us now start a console in AdminVM (dom0) and play a bit with these
mechanisms.
Let’s start with something very simple and let us take a look at the properties
of the AdminVM (in the current Qubes implemented by Xen’s dom0):
[user@dom0 ~]$ qvm-prefs dom0
default_dispvm D fedora-25-dvm
label - black
name D dom0
qid D 0
uuid D 00000000-0000-0000-0000-000000000000
As we can see, there aren’t many properties for the AdminVM, and none of them
can be modified by the user or admin. While we’re here, we should mention there
exists a similar tool, qubes-prefs which allows one to view and modify the
global system properties, and these properties should not be confused with
the properties of the AdminVM:
[user@dom0 ~]$ qubes-prefs
check_updates_vm D True