RT @SwiftOnSecurity: Security isn't about broken parts. Parts break all the time.
Security is understanding the leverage and traversal between working parts.
Security is understanding the leverage and traversal between working parts.
RT @pwnallthethings: Don't assume you're not important enough to hack. One of DC Leaks' victims was a WH intern. And phishing is easy and low risk for hackers.
Comment on What’s New in the Xen Project Hypervisor 4.9? by fbifido
https://blog.xenproject.org/2017/06/28/whats-new-in-the-xen-project-hypervisor-4-9/#comment-399
When is xen getting a native hyperconverged system/feature?
native unmap for NFS?
Please & Thanks.
https://blog.xenproject.org/2017/06/28/whats-new-in-the-xen-project-hypervisor-4-9/#comment-399
When is xen getting a native hyperconverged system/feature?
native unmap for NFS?
Please & Thanks.
Comment on Best Quality and Quantity of Contributions in the New Xen Project 4.6 Release by Xen 4.6 strengthens security and Intel support – Technology Up2date
https://blog.xenproject.org/2015/10/13/xen-4-6/#comment-404
[…] Xen Project has released version 4.6 of its hypervisor project that helps power Amazon EC2 and other major cloud […]
https://blog.xenproject.org/2015/10/13/xen-4-6/#comment-404
[…] Xen Project has released version 4.6 of its hypervisor project that helps power Amazon EC2 and other major cloud […]
RT @rootkovska: I'm glad the defenses we've built into @QubesOS yrs ago could finally be appreciated, as attackers seem to move to target net/USB stacks :) https://t.co/F6MnSeg2VR
Twitter
mig5
An attacker within range may be able to execute arbitrary code on the Wi-Fi chip” https://t.co/1osz0DN3YB I need a @QubesOS phone…
ProTip: set Qubes firewall for your build VM to allow only https (& perhaps specific IPs) or no network at all, to assure more secure build. https://t.co/57TrnB73Zk
Twitter
Jann Horn
Especially funny when the sources are gpg-signed but pull dependencies over git:// and http:// without any visible checksum/sig checks https://t.co/Y6DFq7PqZF
Recap of LinuxCon China and Xen Project’s Growth in the Region
https://blog.xenproject.org/2017/07/25/recap-of-linuxcon-china-and-xen-projects-growth-in-the-region/
It’s been a very busy month or so for the Xen Project. During mid-June, I was lucky to attend and speak at LinuxCon + ContainerCon China held in Beijing. There I spoke on the topic of securing embedded systems with the hypervisor and live patching, virtual machine introspection and vulnerability management alongside my colleague Cheng Zhang of Citrix. […]
https://blog.xenproject.org/2017/07/25/recap-of-linuxcon-china-and-xen-projects-growth-in-the-region/
It’s been a very busy month or so for the Xen Project. During mid-June, I was lucky to attend and speak at LinuxCon + ContainerCon China held in Beijing. There I spoke on the topic of securing embedded systems with the hypervisor and live patching, virtual machine introspection and vulnerability management alongside my colleague Cheng Zhang of Citrix. […]
RT @andrewdavidwong: Fedora 24 is approaching EOL. We recommend upgrading Fedora-based TemplateVMs and StandaloneVMs to Fedora 25.
https://t.co/edIxpMQhlU
https://t.co/edIxpMQhlU
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.
Recommended Fedora 25 TemplateVM Upgrade for Qubes 3.2
https://www.qubes-os.org/news/2017/07/29/fedora-25-upgrade/
Fedora 24, one of the supported TemplateVM versions (https://www.qubes-os.org/doc/supported-versions/#templatevms) in Qubes 3.2, is
scheduled to reach EOL (end of life) approximately
one month (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule) after the release of Fedora 26,
which was on 2017-07-11. This places the expected EOL date for Fedora 24
somewhere in the second week of August.
Options for migrating to Fedora 25 are now available for Qubes 3.2.
If you’re currently using Fedora 24 (or older) TemplateVMs or StandaloneVMs,
we strongly recommend upgrading them to Fedora 25 before then. We provide
step-by-step instructions (https://www.qubes-os.org/doc/template/fedora/upgrade-24-to-25/) for upgrading your existing TemplateVMs
and StandaloneVMs in-place.
We also provide fresh Fedora 25 TemplateVM packages through the official
Qubes repositories, which you can get with the following commands (in dom0).
Standard Fedora 25 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-25
Minimal (https://www.qubes-os.org/doc/templates/fedora-minimal/) Fedora 25 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-25-minimal
After upgrading to a Fedora 25 TemplateVM, please remember to set all
qubes that were using the old template to use the new one. This can be
done in dom0 either with the Qubes VM Manager or with the qvm-prefs
command-line tool.
Please note that no user action is required regarding the OS version in
dom0. If you’re using Qubes 3.2, there is no dom0 OS upgrade available,
since none is currently required. For details, please see here (https://www.qubes-os.org/doc/supported-versions/#dom0).
If you’re using an older version of Qubes, we strongly recommend that
you upgrade to 3.2, as older versions are no longer supported.
https://www.qubes-os.org/news/2017/07/29/fedora-25-upgrade/
Fedora 24, one of the supported TemplateVM versions (https://www.qubes-os.org/doc/supported-versions/#templatevms) in Qubes 3.2, is
scheduled to reach EOL (end of life) approximately
one month (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule) after the release of Fedora 26,
which was on 2017-07-11. This places the expected EOL date for Fedora 24
somewhere in the second week of August.
Options for migrating to Fedora 25 are now available for Qubes 3.2.
If you’re currently using Fedora 24 (or older) TemplateVMs or StandaloneVMs,
we strongly recommend upgrading them to Fedora 25 before then. We provide
step-by-step instructions (https://www.qubes-os.org/doc/template/fedora/upgrade-24-to-25/) for upgrading your existing TemplateVMs
and StandaloneVMs in-place.
We also provide fresh Fedora 25 TemplateVM packages through the official
Qubes repositories, which you can get with the following commands (in dom0).
Standard Fedora 25 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-25
Minimal (https://www.qubes-os.org/doc/templates/fedora-minimal/) Fedora 25 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-25-minimal
After upgrading to a Fedora 25 TemplateVM, please remember to set all
qubes that were using the old template to use the new one. This can be
done in dom0 either with the Qubes VM Manager or with the qvm-prefs
command-line tool.
Please note that no user action is required regarding the OS version in
dom0. If you’re using Qubes 3.2, there is no dom0 OS upgrade available,
since none is currently required. For details, please see here (https://www.qubes-os.org/doc/supported-versions/#dom0).
If you’re using an older version of Qubes, we strongly recommend that
you upgrade to 3.2, as older versions are no longer supported.
Forwarded from Pavel Durov
Since some journalists don’t read my Telegram channel (a shame!), I made a Telegraph story about rumors on Telegram moving servers to weird places. It repeats some of the stuff from the last two posts from here, but could be useful as a summary of all our CDN-related posts. Spread the word!
http://telegra.ph/On-Rumors-About-Telegram-Servers-in-Weird-Places-07-30
http://telegra.ph/On-Rumors-About-Telegram-Servers-in-Weird-Places-07-30
Telegraph – Pavel Durov
On Rumors About Telegram Servers in Weird Places
There are some reports that the Iranian Minister of Communication Mahmoud Vaezi said that "Telegram moved some of its servers to Iran". Since there are no Telegram servers in Iran, this is probably another piece of fake news or incorrect translation. But…
RT @rootkovska: FWIW, Qubes' main goal & challenge is in how to provide *integration* on top of isolated compartments, without negating the isolation... https://t.co/7qSLP7Yp65
Twitter
Paul Harvey
@daveaitel Qubes for isolation, grsec for integrity, containers because Linux user/process isolation is now meaningless on desktops
Qubes OS 4.0-rc1 has been released!
https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/
Finally, after years of work, we’re releasing the first release candidate for
Qubes 4.0!
Next Generation Qubes Core Stack for better integration
No doubt this release marks a major milestone in Qubes OS development. The
single most import undertaking which sets this release apart, is the complete
rewrite of the Qubes Core Stack. We have a separate set of posts detailing the
changes (Why/What/How), and the first post is planned to be released in the
coming 2 weeks.
This new Core Stack allows to easily extend the Qubes Architecture in new
directions, allowing us to finally build (in a clean way) lots of things we’ve
wanted for years, but which would have been too complex to build on the “old”
Qubes infrastructure. The new Qubes Admin API, which we introduced in a
recent post (https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/), is a prime example of one such feature.
(Technically speaking, we’ve neatly put the Admin API at the heart of the new
Qubes Core Stack so that it really is part of the Core Stack, not merely an
“application” built on top of it.)
There are many more benefits that the new Core Stack brings besides the Admin
API. Just to name a few that might be most visible to the user or admin:
Simpler to customize and more flexible Disposable VMs,
More flexible and expressive (qrexec) policy definitions,
Flexible VM volume manager (easy to keep VMs on external drives, or in
memory-only),
… and many more! The new Core Stack also brings lots of simplifications for
developers of Qubes-specific apps and services. Again, we plan to publish posts
about all these cool new features in the coming weeks and months.
One last important comment is that all the work we have done in this area has
been Xen-agnostic, aligned with our long-stated goal (https://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html) to make
Qubes easily portable between different VMMs (hypervisors) and even non-VM-based
systems, such as container-based ones.
Fully virtualized VMs for better isolation
Another important change in this release (this time Xen-specific) is that we
have ditched para-virtualized mode and embraced fully-virtualized mode for
Qubes VMs. The reason for this move has been entirely security-related, as
explained here (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt#L92-L132) and here (https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/).
Originally, we planned to utilize the PVH mode of virtualization, which combines
the benefits of processor virtualization technologies (VT-x and EPT), allowing
for simpler code in the hypervisor, thus improving security, with
paravirtualized drivers for better performance and improved security due to
simplified interfaces to virtualized devices. Even though we have long been
using (https://blog.invisiblethings.org/2012/03/03/windows-support-coming-to-qubes.html) isolated stub domains to keep device I/O
emulators outside of the TCB, these stub domains themselves run in PV mode,
which we are now moving away from.
Sadly, due to the Linux kernel still not fully supporting this PVH mode
(specifically problems with booting the kernels in this mode (http://markmail.org/message/ddds3tb4b23gmtgo)),
we decided to go with the HVM-based VMs for this rc1 release. We plan to switch
to full PVH either in the later rc-releases, or in 4.1, depending on the
progress of PVH support in the Linux kernel.
Also, as an additional last-minute issue, we discovered that PCI pass-through
does not work that well on some systems when using HVM virtualization. Typically
this affects USB VMs and only on some systems. Nevertheless, as a precaution, in
the default installation we decided to switch the mode of virtualization for
these VMs back to PV mode. (The new Core Stack allows one to do this with the
https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/
Finally, after years of work, we’re releasing the first release candidate for
Qubes 4.0!
Next Generation Qubes Core Stack for better integration
No doubt this release marks a major milestone in Qubes OS development. The
single most import undertaking which sets this release apart, is the complete
rewrite of the Qubes Core Stack. We have a separate set of posts detailing the
changes (Why/What/How), and the first post is planned to be released in the
coming 2 weeks.
This new Core Stack allows to easily extend the Qubes Architecture in new
directions, allowing us to finally build (in a clean way) lots of things we’ve
wanted for years, but which would have been too complex to build on the “old”
Qubes infrastructure. The new Qubes Admin API, which we introduced in a
recent post (https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/), is a prime example of one such feature.
(Technically speaking, we’ve neatly put the Admin API at the heart of the new
Qubes Core Stack so that it really is part of the Core Stack, not merely an
“application” built on top of it.)
There are many more benefits that the new Core Stack brings besides the Admin
API. Just to name a few that might be most visible to the user or admin:
Simpler to customize and more flexible Disposable VMs,
More flexible and expressive (qrexec) policy definitions,
Flexible VM volume manager (easy to keep VMs on external drives, or in
memory-only),
… and many more! The new Core Stack also brings lots of simplifications for
developers of Qubes-specific apps and services. Again, we plan to publish posts
about all these cool new features in the coming weeks and months.
One last important comment is that all the work we have done in this area has
been Xen-agnostic, aligned with our long-stated goal (https://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html) to make
Qubes easily portable between different VMMs (hypervisors) and even non-VM-based
systems, such as container-based ones.
Fully virtualized VMs for better isolation
Another important change in this release (this time Xen-specific) is that we
have ditched para-virtualized mode and embraced fully-virtualized mode for
Qubes VMs. The reason for this move has been entirely security-related, as
explained here (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt#L92-L132) and here (https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/).
Originally, we planned to utilize the PVH mode of virtualization, which combines
the benefits of processor virtualization technologies (VT-x and EPT), allowing
for simpler code in the hypervisor, thus improving security, with
paravirtualized drivers for better performance and improved security due to
simplified interfaces to virtualized devices. Even though we have long been
using (https://blog.invisiblethings.org/2012/03/03/windows-support-coming-to-qubes.html) isolated stub domains to keep device I/O
emulators outside of the TCB, these stub domains themselves run in PV mode,
which we are now moving away from.
Sadly, due to the Linux kernel still not fully supporting this PVH mode
(specifically problems with booting the kernels in this mode (http://markmail.org/message/ddds3tb4b23gmtgo)),
we decided to go with the HVM-based VMs for this rc1 release. We plan to switch
to full PVH either in the later rc-releases, or in 4.1, depending on the
progress of PVH support in the Linux kernel.
Also, as an additional last-minute issue, we discovered that PCI pass-through
does not work that well on some systems when using HVM virtualization. Typically
this affects USB VMs and only on some systems. Nevertheless, as a precaution, in
the default installation we decided to switch the mode of virtualization for
these VMs back to PV mode. (The new Core Stack allows one to do this with the
flip of a switchproperty :). Here our rationale is that it’s still much
better to have PV-based isolation for USB VMs rather than not having USB
controllers isolated at all! Again, we anticipate this will be resolved in the
upcoming rc-releases.
New approach to UX/UI for better integration
In Qubes 4.0 we also decided (https://github.com/QubesOS/qubes-issues/issues/2132) to redesign the User
Experience (UX) a little bit. Aligned with our long-term vision to hide as
much of the Qubes internals from the casual user as practically viable, we made
a bold move and… removed the Qubes Manager altogether!
Instead, we believe it makes more sense to utilize as much of the infrastructure
already built by professional UX designers as possible. Consequently, most of
the Qubes persistent configuration (creation of new VMs, changing their settings
as well as the global ones) is accessible through the standard application menu
aka “Start Menu”. In addition, we wrote two tiny widgets, which should work with
most desktop environments compatible with Qubes (currently this list includes
the default Xfce4, the once-default KDE, the community-maintained i3, and
awesome). These widgets are used to show live info about the running system
state, such as which VMs are currently running, their memory usage, as well as
which devices are available to connect to different VMs (and yes, now it is
possible to connect USB devices using the GUI, a long requested feature by many
of our users).
Advanced Qubes users will surely appreciate, on the other hand, the much more
flexible and powerful qvm-* tools, such as the completely rewritten qvm-ls
and qvm-prefs, to name just two (again, more on them in the upcoming posts).
Better compatibility and all the rest
Besides the above, there have been lots of other improvements and bug fixes
compared to the 3.2 release. We list most of them in the release
notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/).
Perhaps one worth singling out here, in the context of hardware compatibility,
is the upgrade of the default dom0 distribution to Fedora 25. (Before we
decompose dom0 into separate GUI and Admin VMs, which we plan to do in 4.1, the
dom0 distribution determines how well the GPU is supported.)
Summary
Qubes 4.0 is a significant milestone on our roadmap to implement a reasonably
secure desktop/client OS based on the “Security by Compartmentalization”
principle (using “Explicit Partitioning Model”, in contrast to the recently
popular “Sandboxing Model”).
This is the first release candidate of a largely rewritten complex system, and
no doubt early adopters will discover some rough edges here and there. Despite
our increasingly sophisticated automatic testing infrastructure, this is simply
unavoidable. Consequently, if you want to use Qubes for production, stick to
Qubes 3.2 until we release (https://www.qubes-os.org/doc/version-scheme/#release-schedule) the stable version of Qubes 4.0.
But if you would like to start learning and experimenting with the advanced new
features that 4.0 brings, such as the Admin API, or would like to help us reach
a stable 4.0 more quickly, or you’re just curious, or want to show off to your
friends what a bleeding edge system you have, then please do so and go straight
to the download page (https://www.qubes-os.org/downloads/)!
On behalf of the whole Qubes OS Core Team (https://www.qubes-os.org/team/),
joanna.
better to have PV-based isolation for USB VMs rather than not having USB
controllers isolated at all! Again, we anticipate this will be resolved in the
upcoming rc-releases.
New approach to UX/UI for better integration
In Qubes 4.0 we also decided (https://github.com/QubesOS/qubes-issues/issues/2132) to redesign the User
Experience (UX) a little bit. Aligned with our long-term vision to hide as
much of the Qubes internals from the casual user as practically viable, we made
a bold move and… removed the Qubes Manager altogether!
Instead, we believe it makes more sense to utilize as much of the infrastructure
already built by professional UX designers as possible. Consequently, most of
the Qubes persistent configuration (creation of new VMs, changing their settings
as well as the global ones) is accessible through the standard application menu
aka “Start Menu”. In addition, we wrote two tiny widgets, which should work with
most desktop environments compatible with Qubes (currently this list includes
the default Xfce4, the once-default KDE, the community-maintained i3, and
awesome). These widgets are used to show live info about the running system
state, such as which VMs are currently running, their memory usage, as well as
which devices are available to connect to different VMs (and yes, now it is
possible to connect USB devices using the GUI, a long requested feature by many
of our users).
Advanced Qubes users will surely appreciate, on the other hand, the much more
flexible and powerful qvm-* tools, such as the completely rewritten qvm-ls
and qvm-prefs, to name just two (again, more on them in the upcoming posts).
Better compatibility and all the rest
Besides the above, there have been lots of other improvements and bug fixes
compared to the 3.2 release. We list most of them in the release
notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/).
Perhaps one worth singling out here, in the context of hardware compatibility,
is the upgrade of the default dom0 distribution to Fedora 25. (Before we
decompose dom0 into separate GUI and Admin VMs, which we plan to do in 4.1, the
dom0 distribution determines how well the GPU is supported.)
Summary
Qubes 4.0 is a significant milestone on our roadmap to implement a reasonably
secure desktop/client OS based on the “Security by Compartmentalization”
principle (using “Explicit Partitioning Model”, in contrast to the recently
popular “Sandboxing Model”).
This is the first release candidate of a largely rewritten complex system, and
no doubt early adopters will discover some rough edges here and there. Despite
our increasingly sophisticated automatic testing infrastructure, this is simply
unavoidable. Consequently, if you want to use Qubes for production, stick to
Qubes 3.2 until we release (https://www.qubes-os.org/doc/version-scheme/#release-schedule) the stable version of Qubes 4.0.
But if you would like to start learning and experimenting with the advanced new
features that 4.0 brings, such as the Admin API, or would like to help us reach
a stable 4.0 more quickly, or you’re just curious, or want to show off to your
friends what a bleeding edge system you have, then please do so and go straight
to the download page (https://www.qubes-os.org/downloads/)!
On behalf of the whole Qubes OS Core Team (https://www.qubes-os.org/team/),
joanna.
RT @MikaelThalen: Or you secure copy & paste all links into a @QubesOS disposable VM & shame the security team for shaming you https://t.co/Fg7QgeRMN1
Twitter
Farhad Manjoo 🐝
The NYT security people regularly send us fake emails, to test us. Then they shame you if you click. It's a good practice. Keeps you sharp
RT @micahflee: @Hak5 @QubesOS protects against this if you use a USB VM. You can tell it to not trust USB keyboards or to ask before allowing them to type 17/18 https://t.co/MRhNEeY1l3
Twitter
Micah Lee
@Hak5 @QubesOS protects against this if you use a USB VM. You can tell it to not trust USB keyboards or to ask before allowing them to type 17/18
Presentations about QubeOS on Debconf later today.
https://debconf17.debconf.org/talks/16/
Recordings:
http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/
https://debconf17.debconf.org/talks/16/
Recordings:
http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/
The @QubeOS talk at Debconf starts here in a couple of minutes: https://debconf17.debconf.org/schedule/venue/4/