Today we're release the second release candidate (rc2) for Qubes OS R2. There are currently no more open tickets for the final R2 release, and we hope that what we release today is stable enough and so will be identical, or nearly identical, to the final R2 ISO, which we plan to release after the summer holidays. Download and installation instructions are here.
After Qubes rc1 release a few months ago we have been hit by a number of problems related to unreliable VM start-ups. The most prevalent problem has been traced down to an upstream bug in systemd, which just happened to be manifesting on Qubes OS due to specific conditions imposed by our startup scripts.
Actually, it has not been the first time when some things related to VM bootup or initialization didn't work quite well on Qubes, a side effect of heavy optimizations and stripping down we do in order to make the VMs as light weight as possible. E.g. we don't start most of the Desktop Environment which otherwise is assumed to be running by various desktop-related applications and services. In most cases these are really NOTOURBUG kind of problems, yet we just happen to be unlucky they manifest on Qubes. We do need more help from the community with testing, debugging and patching such NOTOURBUG problems in the upstream. The more people use Qubes OS, the higher the chances such problems will be addressed much quicker. Ideally, in the future, we could partner with a Linux distro that would include Qubes AppVM as one of the test cases.
Speaking of different Linux distros -- we have also recently built and released an experimental (“beta”) Debian template for Qubes AppVMs, a popular request expressed by our users for quite some time. It can be readily installed with just one command, as described in the wiki. It is supposed to behave as a first class Qubes AppVM with all the Qubes signature VM integration features, such as seamless GUI virtualization, secure clipboard, secure file copy, and other integration, all working out of the box. Special thanks to our community contributors for providing most of the patches required for porting of our agents and other scripts to Debian. This template is currently provided via our templates-community repo, but it nevertheless has been built and signed by ITL, and is also configured to fetch updates (for Qubes tools) from our server, but we look forward for somebody from the community to take over from us the maintenance (building, testing) of the updates for this template.
Also in our "Templates Appstore" you can find now an experimental “minimal” fedora-based template, which might be used by more advanced users to build customized special-purpose VMs and templates.
We have also moved our Wiki server to a bigger EC2 instance so it could better handle the increased traffic and also added a real CA-signed SSL certificate! But I encourage people to read why this is mostly irrelevant from the security standpoint and why they should still be checking signatures on the ISOs.
We also got a new logo (actually we never really had our own logo before). This also means Qubes now got its own distinct set of themes for installer, plymouth and, of course, a bunch of cool wallpapers with Qubes logo nicely engraved on them. However, it turned out that convincing KDE to set our wallpaper as a default one exceeds the collective mental abilities of ITL, and so one needs to right-click on the desktop and choose one of the Qubes-branded wallpapers manually after install or upgrade.
Every once in a while people (re-)discover that monolithic kernel-based desktop operating systems are not the best solution whenever the user even remotely cares about security...
Yes, USB inherent insecurity, as well as widespread GUI insecurity, or networking stack insecurity, trivial physical insecurities, or sick permissions model as used in most desktop systems, have all been known facts for years. The recognition of these problems has been the primary motivator for us to start the work on Qubes OS back in 2009/2010.
And yes, Qubes running on an appropriate hardware (specifically with Intel VT-d) can solve most of these problems. Correction: Qubes OS can allow the user or administrator to solve these problems, as unfortunately this still requires some configuration decisions made by the human operator. So today Qubes R2 is like a sports manual transmission, which requires a bit of skill to get most out of it. In the near future I see no reason why we should not be offering the "automatic 8-speed transmission" edition of Qubes OS. We just need more time to get there. The R3 release (Odyssey-based), whose early code is planned to be released just after the "final" R2, so sometime in September, is all about bringing us closer to that "automatic transmission" version.
With my 10+ years of experience as a system-level security researcher, I believe there is no other way to go. Don't get deluded that safe languages or formally verified microkernels could solve these problems. Security by Isolation, done sensibly, is the only way to go (of course it doesn't preclude making use of some formally verified components, like e.g. microkernel in place of Xen, at least in some editions of Qubes).
Finally one more announcement for today: after writing this blog for 8 years, I've suddenly felt like I might need to try also some new form of expression... And so, for a few days, I now have a twitter account (@rootkovska), which I hope to use for updates on Qubes, as well as more general commentary on various things happening in IT security.
Wednesday, August 06, 2014
Qubes OS R2 rc2, Debian template, SSLed Wiki, BadUSB, and more...
Posted by Joanna Rutkowska at Wednesday, August 06, 2014
Labels: os security, qubes, usb
Subscribe to: Post Comments (Atom)
Looking forward to trying it out. Pleased Qubes is moving forward.
Congrats to you and team.
Joanna, your efforts do not go unappreciated!
I've discovered and been a fan of QubesOS for only the past 6 months, but even now I see a daily growing census of users who appreciate your work and who understand the advantage of such a system. Many thanks to you and your team!
And by the way, thanks for the correct pronunciation of your name. I've been getting it wrong until now...
Great work. I know it is the icing on the cake but I find the logo brilliant. It capture very well the spirit of the OS, a single user OS with strong isolation.
Great work as always, Joanna. With regards to your comments about formally verified microkernels, seL4 was just open sourced so now could be the time to replace Xen with seL4 if you're considering it for a future release :)
Joanna, Great to see your fantastic intellect manifested in an OS of such class.
Thanks. But don't forget Qubes is fruit of not just my work:
Joanna, regarding the dom0 and it's disaggregation - have you considered Xen's Mirage or NetBSD's rumpkernels - these seem like the projects made just for the task?
If Qubes OS R2 is about to release it is time to plan Qubes OS R3 :)
1. Do you plan to support ARMv8(-A) in Odyssey-based Qubes OS R3?
2. What are yours feelings about security of ARMv8 based (micro-)servers?
For example AMD released development board with ARMv8 based Opteron™ A1100 System on a Chip with two integrated controllers of Ethernet and SCP (system control processor). Ethernet related chip in context of Loic Duflot's and Yves-Alexis Perez attack on network cards. SCP in context of its own security and question: Can SCP prevent various attacks?
The "USB stick reprogrammed to include a fake keyboard" attack seems particularly hazardous. Does/will Qubes have any countermeasures?
Perhaps whenever a new keyboard device appears it could be isolated from the rest of the system until it is used to enter a valid user's credentials?
Congrats for the hard work !
Does now Windows AppVMs support different keyboard layouts (after VM tools are installed on Guest OS) so that we are not only forced to use QWERTY ?
KDE default wallpaper:
-> change to a Qubes one?
Post a Comment