Wednesday, September 12, 2012

Many people ask how does Qubes OS differ from other approaches to desktop security. Today I'm trying to answer the most popular questions.

Why bother with Qubes OS, if any Linux/BSD already allows to setup different user accounts, or some form of light-weight containers or sandboxes, such as chroot, LXC, SELinux?

First, if you use Xorg or similar
X-based server as your GUI server, and this is what nearly all
Linux, and most of the other non-Windows OSes use, then you don't
have any form of GUI-level isolation, which is essential for a
desktop system. I wrote more about this surprising problem some time ago.
Proper GUI-level isolation was one of the main goals for Qubes.

Second, all mainstream desktop OSes,
such as Windows, Linux, BSD, even OSX, are all based on a monolithic
kernels, which present a significant security problem. This is
because a typical monolithic kernel of a contemporary desktop OS
contains tens of millions of lines of code, and to make it worse,
most of this code is reachable from (untrusted) applications via all
sorts of APIs, making the attack surface on the kernel huge. And it
requires just one successful kernel exploit to own the whole system,
bypassing any security mechanisms that might have been built on top
of it, such as SELinux, LXC, etc.

Additionally, all the various drivers,
networking and USB stacks, are also hosted in the kernel, making
attacks via buggy networking
(e.g. via buggy 802.11 stacks
or buggy firmware) or USB stacks a practical possibility. And there is essentially nothing one can do
about it, when using an OS based on a monolithic kernel.

In Qubes, on the other hand, we use Xen
hypervisor to provide security isolation between domains, and Xen is
just a few hundred of thousands lines of code. It also doesn't need
to provide all sorts of APIs to applications, because the Xen
hypervisor is essentially only interested in CPU scheduling, memory
management and power management, and very few things beyond that.
Most notably, the Xen hypervisor knows nothing about networking, disk
storage, filesystems, USB stacks, etc, as all those tasks are
delegated to (often untrusted) service VMs.

How is Qubes better than just
running a bunch of VMs in VMWare or Virtual Box?

First, products
such as VMWare Workstation or Fusion, or Virtual Box, are all
examples of type II hypervisors (sometimes called “hosted VMMs”),
which means that they run inside a normal OS, such as Windows, as
ordinary processes and/or kernel modules. This means that they use
the OS-provided services for all sorts of things, from networking,
USB stacks, to graphics output and keyboard and mouse input, which in
turn implies they can be only as secure as the hosting OS is. If the hosting OS got compromised, perhaps via a bug in its DHCP
client, or USB driver, then it is a game over, also for all your VMs.

Second, those
popular consumer type II VMM systems have not been designed with
security as a primary goal. Instead, their main focus has been on easy of use, performance, and providing seamless integration of
the guest OS(es) with the host OS. Especially the latter, which
involves lack of good method to identify which domain a given application belongs to (so, lack of trusted Window Manager), support for shared clipboards which every other VM can steal, insecure file sharing methods, and others, all make it not a very desirable
solution when strong domain isolation is important. (This is not to imply
that Qubes doesn't support clipboard or file sharing between domains,
it does – it's just that we do it in a secure way, at least so we
believe). On the other
hand, there are many usability improvements in Qubes that are
specific to multi-domain system, and which you won't find in the
above mentioned products, such as trusted Window Manager that, while maintaining great seamless integration of all the applications onto a common desktop, still allows the user to always know which domain owns which window, support for advanced networking setups,
per-domain policies, the just mentioned secure mechanisms for clipboard and filesystem
sharing, and many other.
Qubes also focuses on making the VMs light-weight so that it was possible to run really a lot of them at the same time, and also on mechanism to allow for secure filesystem sharing between domains (templates).

Finally, the
commercial hosted VMMs are really bloated pieces of code. They
support everything and the kitchen sink (e.g. Open GL exposed to VMs,
and various additional interfaces to allow e.g. drag and drop of
files to/from the VM), and so, the attack surface on such a VMM
system is orders of magnitude bigger than in case of Qubes OS.

How does Qubes compare to [your favourite academic microkernel]?

While the Xen
hypervisor can indeed be considered a microkernel if you're not a
strict terminology freak, Qubes itself is much more than just the
hypervisor. Qubes is everything that is needed to build a reasonably
secure desktop OS on top of
a baremetal hypervisor (or microkernel). Theoretically, with just a
few cosmetic changes (at least architecture-wise), Qubes could
perhaps swap the Xen hypervisor for some other hypervisor or
microkernel, such as perhaps Hyper-V, KVM, or some more exotic one.
Thus, it makes little sense to compare Qubes with a hypervisor or
microkernel project. What makes sense is to compare the Xen
hypervisor, as used in Qubes, with some other hypervisor or
microkernel.

Ok, so how does
Xen compare with other hypervisors or microkernels out there? We
think Xen is unique because it combines an elegant architecture (type
I, baremetal, hypervisor) with a number of practical features, such
as power management, support for Intel VT-d and driver domains,
support for both para-virtualizaed, and fully-virtualized VMs, and
many more, not found in e.g. academic microkernels/hypervisor
projects, that otherwise seem attractive from the architecture point
of view.

How is Qubes better than Google
Chrome OS?

First, Chrome OS
is not a general purpose OS. Second, it's based on Linux with all its
security limitation that are a result of using a monolithic kernel
described above (e.g. all the networking and USB stacks in the kernel
without a possibility to deprivilige them). Not being a traditional
general purpose OS, Chrome is able to avoid many of the challenges of
desktop computing, such as the need to define security domains,
inter-domain file exchange (as there is essentially no filesystem
visible to the user), and others, which is good, of course. But then
again, Chrome OS is essentially just an environment to run the Chrome
Browser, so the comparison to Qubes is a bit of a misunderstanding.

Technical aspects aside, there is always the privacy concern associated with running everything in a browser – why would all
my private data be managed and accessible to some 3rd party
organizations and their administrators?

You must have
heard about the super secure military-grade, formally verified, 100%
certified, and generally “unbreakable” operating systems made by
companies such as Green Hills,
Lynx Works,
and others. How do they compare to Qubes OS?

Really, I have no
idea. For a mere mortal like myself (and perhaps not a US citizen), it seems impossible to get any
more technical documentation of those systems (anything beyond the
marketing pseudo-technical gibberish), not to mention a trial copy to
play with...

Thus, from my point of view, those systems are just a
vaporware. If you, my dear reader, are privileged enough to have
access to such system, then good for you, but don't expect me to
treat seriously a security product that is not available for a wider
audience to touch and play with... (And the Chineese surely have the copies already to play with ;)

How is Qubes different than
Bromium's “micro virtualization” solution?

Many people asked recently about the
Bromium's upcoming product and how it differs from Qubes OS.
Unfortunately there are few public information available on this
product – essentially there is one not-very-technical whitepaper
and there are Ian Pratt's presentation slides from the recent XenSummit about u-Xen, apparently a
hypervisor that is to be ultimately used in their upcoming product.

The whitepaper suggests that Bromium is
based on a hosted (type II) hypervisor running within a normal Window
OS, and that this hypervisor is used to spawn a new “micro VM”
for each new “task”, where apparently the task might be something as
granular as opening a new tab in a Web browser, which makes it
somehow similar to Google Chrome's approach. Clearly, the Bromium's main goal
seem to be to automate the
process of creating separation domains, which is in contrast with
what we do on Qubes OS, where the user is required to define the
domains explicitly.

The
Pratt's slides provide also some technical insight into how Bromium
intends to secure their hypervisor. As just discussed above, a
hosted hypervisor must normally trust the hosting OS, in this case
Windows, which, for obvious reasons, is not a good
idea from the security standpoint. Pratt, however, clearly states
that “host (...) can not interfere with the privacy or integrity of
the hypervisor or other guests” (slide #8). This is a strong
statement, so let's take a closer look at their approach to this problem.

The
Bromium's idea of how to make their hypervisor (and the VMs)
protected from a potentially malicious host OS is not really
breakthrough: the slides suggest to “deprivilege the host into a
VT-container” (I think the verb to bluepill
is now an accepted term for such action ;), and to remove the host's
access to the hypervisor pages (via EPT), as well as protect DMA
access from devices via VT-d, plus to make this all sensible, use
DRTM scheme such as Intel TXT, to load such a hypervisor from within
a potentially untrusted OS.

So,
what's wrong with the idea of a load-on-the-fly-secure-VMM-system?
Isn't Ian Pratt correct that one could protect its memory and
execution from the interference of the host? Actually that is
possible – Intel TXT, VT-x, VT-d, and EPT give us means to achieve
that (although there are a number of catches here). But he's missing
one important point: it's the untrusted OS that still owns and manages the input
devices (e.g. via USB stacks and drivers) and, most importantly, the output (via the GUI
subsystem and drivers). Ensuring that the host OS cannot interfere
(e.g. sniff the screen of trusted applications) might be very
difficult, or even impossible, in practice.

If I ever was to break the security of such a system, I would just follow the simple way:

1) Infect the host e.g. via one of the many USB attacks (remember they cannot have sandboxed USB driver domain, as they have only a type II hosted hypervisor),

2) Hook somewhere into the GUI subsystem and keep recoding all the interesting data from the screen...

... or something like that ;)

There
are also many other things that needs to be answered and which the publicly available documents are silent about, such as e.g. how does the system
handle installation of new applications? How is clipboard and file
exchange between (micro)VMs handled? How large are the interfaces
exposed to each (micro)VM? For now, without a solid documentation
available, and without any code to play with, it is just another
vaporware for me. (Interestingly there seem to be Bromium's Beta program, which however doesn't seem to be working, at least not for me -- I tried to signup twice, but never got any confirmation or response...?)

How is Qubes different from Xen
Client?

In many aspects, Xen Client
might be the most similar product to Qubes OS. Like Qubes, it is
based on the Xen hypervisor and so it is also a standalone OS, that
one must install instead of one's favorite system, and also, like
Qubes, it is targeted for desktop systems, and also offers a
possibility to run a few VMs at a time.

However, XenClient has been designed
with a different goal in mind, namely as a “Virtual Desktops To Go”
solution, while Qubes has been designed to provide seamless
experience for secure multi-domain desktop system. As a result, lots
of focus in Qubes has been put on creating trusted GUI subsystem,
support for advanced networking configurations, secure inter-VM
clipboard and file sharing, secure method to reuse the same
filesystem as a basis for the AppVMs, and also to optimize the AppVMs
so they start almost instantly and take little memory, so that one
could easily run many of them at the same time. All those things seem
to be missing from Xen Client (as well as solid technical
documentation about its design).

***

I surely have missed a few other products or approaches -- feel free to point them out in the comments, and I might write a continuation post one day.

Monday, September 03, 2012

After nearly three years of work, I
have a pleasure to announce that Qubes 1.0 has finally been released!
To see the installation instructions and to get an ISO, please go to
this page.

I would like to thank all the
developers who have worked on this project. Creating Qubes OS has been a
great challenge, especially for such a small team as ours, but ultimately,
I'm very glad with the final outcome – it really is a stable and
reasonably secure desktop OS. In fact I cannot think of any more
secure alternative...

I use the term “reasonably secure”,
because when it comes to defensive security it's difficult to use
definite statements (“secure”, “unbreakable”, etc), unless
one can formally prove the whole design and implementation to be 100%
secure.

Unfortunately, contrary to common
belief, there are no general purpose, desktop OSes, that would be
formally proven to be secure. At the very best, there are some parts
that are formally verified, such as some microkernels, but not whole
OSes. And what good is saying that our microkernel is formally
verified, if we continue to use a bloated and buggy X server as our
GUI subsystem? After all, a GUI subsystem has access to all the user
inputs and output, thus it is as much security sensitive, as is the the
microkernel! Or power management subsystem, or filesystem server, or
trusted boot scheme, or ... a dozens of other elements, which just
cannot be forgotten if one wants to talk about a truly secure OS. As
said before, I know of no general-purpose desktop OS that would be
formally proven, and thus that could be called “secure”. You can
also read more about challenges with formal verification microkernels in this article, and especially in this comment from the seL4 project leader.

In Qubes OS we took
a practical approach and we have tried to focus on all those
sensitive parts of the OS, and to make them reasonably secure. And,
of course, in the first place, we tried to minimize the amount of
those trusted parts, in which Qubes really stands out, I think.

So, we believe
Qubes OS represents a reasonably secure OS. In fact I'm not aware of
any other solution currently on the market that would come close when
it comes to secure desktop environment. But then again, I'm biased,
of course ;)

I
wouldn't call Qubes OS “safe”, however, at least not at this
stage. By “safe” I mean a product that is “safe to use”,
which also implies “easy to use”, “not requiring special
skills”, and thus harmless in the hands of an inexperienced user. I
think that Apple iOS is a good example of such a “safe” OS – it
automatically puts each application into its own sandbox, essentially
not relaying on the user to make any security decisions. However, the
isolation that each such sandbox provides is far from being secure,
as various practical attacks have proven, and which is mostly a
result of exposing too fat APIs to each sandbox, as I understand. In Qubes OS, it's
the user that is responsible for making all the security decisions –
how to partition her digital life into security domains,
what network
and other permissions each domain might have, whether to open a given
document in a Disposable VM,
etc. This provides for great flexibility for more advanced users, but the
price to pay is that Qubes OS requires some skills and thinking to
actually make the user's data more secure.

Generally Qubes OS
is an advanced tool for implementing Security by Isolation approach
on your desktop, using domains implemented as lightweight Xen
VMs. It tries to marry two contradictory goals: how to make the
isolation between domains as strong as possible, mainly due to clever
architecture that minimizes the amount of trusted code, and how to
make this isolation as seamless and easy as possible. Again, how the
user is going to take advantage of this isolation is totally left up
to the user. I realize this might be a tricky part for some users and
some usage scenarios, yet, on the other hand, this seems to be the
most flexible and powerful approach we could provide.

Thus people should
realize that by mere fact of using Qubes OS they won't become
automatically more secure – it's how they are going to use
it might make them significantly more secure. A hypothetical exploit for
your favourite web browser would work against Firefox running inside
one of the Qubes VMs just as well as it worked for the same browser
running on normal Linux. The difference that Qubes makes, is that
this attacked browser might be just your for-personal-use-only
browser which is isolated from your for-work-use-only-browser, and
for-banking-use-only-browser.

Finally, even
though Qubes has been created by a reasonably skilled team of people,
it should not be considered bug free. In fact, over the last 3 years
we already found 3 serious bugs/attacks
affecting Qubes OS – one of them in the very code we created, and
two other in Intel hardware. Again, we tried as much as possible to limit the amount of code
that is security sensitive in the first place, yet we are just humans
;) So, I'm very curious to see others' attempts to break Qubes – I
think it might make for a very interesting research. A good starting
point for such research might be this page.
And I know there are individuals out there who apparently only been
waiting for Qubes 1.0 to come out, to get some glory
(yet, it's not clear to me why to attack qemu, which is not part
of the TCB in Qubes, but I guess great minds have their own mysteries
;)

In other words,
please enjoy Qubes OS 1.0, hopefully it could make your digital life
safer!

Please send all
the technical questions regarding Qubes to the qubes-devel mailing list.
Do not send them to me directly, nor post them in this blog's
comments.