[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    Re: [qubes-devel] Qubes + OpenXT
From:       Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date:       2017-01-09 16:02:32
Message-ID: 20170109160231.GC14480 () work-mutt
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Jan 07, 2017 at 10:58:39AM -0800, Eric Shelton wrote:
> A couple of recent events prompted me to look more into the OpenXT project:
> - The recent announcements about Qubes' funding and shift in development 
> priorities.  It is great to hear that Qubes will remain an open source 
> effort.  However, there has consistently only been a small handful of 
> developers active in Qubes -- mainly those being paid by ITL (without 
> Marek, I don't think there would be a Qubes today).  With their priorities 
> being set by commercial clients, it seems less certain what Qubes will 
> focus on, and on what schedule they will get there.  I suppose there just 
> aren't all that many non-ITL open source contributors with the needed Linux 
> internals and Xen internals expertise looking to chip in, and maybe this 
> situation will not change anytime soon.
> - It came to my attention that OpenXT has implemented Linux-based 
> stubdomains using upstream QEMU - an issue long neglected by upstream Xen. 
> Qubes is working on this, and maybe it will be a 4.0 feature.
> 
> A couple of quick summaries of the OpenXT effort:
> http://www.slideshare.net/xen_com_mgr/the-openxt-project-in-2016-christopher-clark-bae-systems
>  http://www.slideshare.net/xen_com_mgr/tricca-xen-summit2014
> 
> OpenXT is also the open source core of a very Qubes-like OS: SecureView:
> https://www.fbcinc.com/e/cdse/presentations/day2/10-SecureView_Overview_-_Capt_Alex_Gwin_-_FINAL_-_Day_2.pdf
>  
> I believe I am reasonably familiar with the Qubes project, and to me there 
> seems to be a significant amount of overlap in the missions and solutions 
> of Qubes and OpenXT - especially where it counts: the "security research" 
> and virtual desktop integration areas.  This also translates into a lot of 
> duplicated effort across these two projects.  OpenXT has their own 
> TPM/AEM/measured launch, PV-USB (implemented long ago, and with Windows 
> support), stub domains (they have long used Linux-based stubdomains, and 
> will be moving up to QEMU 2.6 soon), netvm, and a UIVM that has been 
> separated from dom0.  I'm not saying everything is a one-to-one match with 
> the Qubes architecture, but I can say that Qubes has been, and continues 
> to, spend its precious and limited resources implementing and updating 
> features that are already implemented and being updated in OpenXT.  Also, 
> OpenXT is way ahead of Qubes on Windows guest support (which I suspect is 
> important for the Qubes commercialization path).  There are also many ideas 
> implemented or being worked on in Qubes that strike me as positive 
> improvements for OpenXT: usbvm, seamless desktop, template domains, etc.
> 
> Perhaps it is worth considering (or reconsidering?) bringing the efforts of 
> these two projects together.  OpenXT might offer a reasonable base 
> architecture for Qubes, and allow the Qubes team to not spread itself so 
> thin (Marek and company are tackling problems from the BIOS on up, and that 
> presents a lots of software that is changing (changes in KDE broke the 
> window decoration, Wayland in F25 will surely bring new headaches) and 
> constantly is pulling the Qubes developers away from their core mission. 
> In some ways, isn't this what the HAL effort (which unfortunately does not 
> seen to have achieved much) was about - abstracting Qubes away from the 
> base hypervisor architecture?
> 
> The only comment I have seen from the Qubes developers about OpenXT is 
> criticism of their use of dbus in their interdomain communication 
> architecture (https://twitter.com/rootkovska/status/505024924097196032).  I 
> imagine the Qubes team can find a reasonable way around that.  I understand 
> there is going to be a significant "not invented here" resistance to this 
> idea, but keep in mind that there are at least as many smart and security 
> conscious developers working on OpenXT, too.
> 
> Perhaps another issue is that the developers working on OpenXT, for the 
> most part, work for US defense industry contractors.  SecureView appears to 
> have ties with the NSA and the US Air Force.  On the other hand, I will 
> point out that these same parties are also contributors to upstream Xen and 
> Linux - although among many others (and hypothetically, many more "sets of 
> eyes" - however well that concept actually works in practice).  Plus, 
> somehow people long ago rationalized Tor having arisen from US Naval 
> Research Laboratory and receiving ongoing funding from the US government. 
> For what it is worth, Qubes could be a viable competitor for SecureView 
> (especially if built on OpenXT), if you want to pursue that avenue for 
> commercial funding.
> 
> I love Qubes, and it would be great if it had loads of resources to 
> continue to do everything from the bottom to the top and remain the 
> somewhat independent effort it has been for the last couple of years.  But 
> that is not the case, is it?  If building Qubes on top of OpenXT allows 
> Qubes developers to focus on the unique aspects of Qubes instead of fixing 
> up things being broken by other projects, that would allow Qubes developer 
> hours to be focused on developing the aspects that are unique to Qubes, 
> demonstrate the value of Qubes, and perhaps establish a more sustainable 
> cycle for Qubes (user interest, commercial interest, developer interest, 
> etc.) that better ensures the project can continue.  Plus, I suspect both 
> projects have a lot to gain from each other.  Frankly, otherwise I fear 
> that the Qubes project will, despite the team's best intentions and 
> efforts, fizzle out over the next few years.
> 
> Best,
> Eric
> 

You've touched on an interesting topic: what's the unique value of the Qubes OS
Project? I like to think it is primarily the following aspects:

1. The combination of both offensive and devops expertise in the team,

2. Ability to find reasonable balance between "seeking perfection" on the one
hand ("let's rewrite the whole stack from scratch"), and "conformism" on the
other hand ("maybe this solution can be bypassed trivially, but it still
increases the bar, blah blah blah"),

3. Last but not least: unlike so many recent projects which want to use
virtualization for creation of multiple isolated "computers", Qubes philosophy
has always been to provide one integrated environment built on top of many
isolated VMs.

Now, having the above in mind, lets consider your proposition of potentially
merging with OpenXT, or to use OpenXT as a basis for Qubes OS:

First, I don't think the fact they decided to use the D-Bus protocol as a
universal solution for their inter-VM communication should be considered as
disqualifying reason for us reusing their code. Instead, we should treat it as a
red light for the security competence of the team that have created their
architecture. A Big Red Light with a Roaring Fire Siren, to be more precise.

Indeed, OpenXT, previously known as XenClient XT, has a history of what I see as
bad security architecture decisions. Besides the above-criticized choice of
D-Bus as a fundamental building block for any VM-spanning services, another
striking example is the adoption of GPU pass-through as their primary graphics
virtualization technology.

While I'm sure that the word "pass-through" brings very positive connotations to
most readers ("something that doesn't require much handling from the hypervisor
side"), and also looks great on powerpoint diagrams ("arrows indifferently
crossing the hypervisor box"), in reality GPU pass-through require lots of
complexity on the hypervisor side, which the slides often forget to mention.

E.g. what happens when the real GPU is taken away from the VM? Are we going to
give it some *emulation* for the time being to keep it happy? If so, what if
there is a bug in the emulation code (there surely is, 'cause GPU's are
complex)? What privileges would the VM obtain after exploiting the GPU emulation
code?

On more recent Intel GPUs the situation has presumably improved, but the fact XT
has decided to chose this insecure form of graphics virtualization over the much
more secure approach that we designed for Qubes OS, so many years ago, is
another fact that makes me very uneasy about the security expertise of the XT
team.

(Because of this architecture decision, BTW, what XT people call "UIVM", is not
the same as what we call "GUI domain", and which we plan to introduce some time
after 4.0 release. In XT architecture, UIVM is a natural consequence of the GPU
pass-through model, and is merely a label assigned to one-of-the-many VMs which
can get full pass-through access to the GPU. In Qubes, the GUI domain is planed
to be *the only one* VM granted pass-through access to the GPU, while we would
continue to be using our -- I believe -- very secure GUI virtualization protocol
to allow other VMs to access graphics.)

Last but not least, probably the most fundamental difference between XT and
Qubes (and partly also responsible for some architectural differences) is in the
philosophy. XT attempts to implement the classic
multiple-isolated-(virtual)-computers-inside-one-box model (aka Multi Level
Security, or MLS), which originates from the military world. Qubes, on the other
hand, attempts to provide one secure desktop platform, which uses multiple
isolated VMs to securely decompose various tasks.

I've never quite got convinced by this MLS approach, to be honest. After all,
what's the point of running a few monolithic Windows VMs, if each of them is
still... a buggy, monolithic VM which can get compromised just as easily? Of
course, the official ideology of MLS says that even if an attacker compromises
one of the VMs, then they would not be able to at least leak the data to other,
unclassified networks.[*] In any case, the MLS proponents believe that these
systems could be useful to e.g. stop an insider from stealing gigabytes of
confidential info and leaking them out somewhere. Looks like this might not have
quite worked out for some of the organizations who are well known to promote
this security model (and incidentally also XT and SELinux)... ;)

Contract this to the Qubes approach, where we would like to utilize multiple
domains in order to actually make the domains more difficult to attack. Whether
by making them "disposable", or by splitting the tasks between more than one VM
(and potentially having some of these other VMs as disposable, or easily
recoverable).[**]

All the above complains about XT focus on the architecture. And I'd argue that
for a project like Qubes the proper architecture is something that should always
come first. Or to stay it differently: even the best code cannot be "rescued" if
it implements a bad architecture.

But perhaps they could produce some good code that we could consume
nevertheless? Well, maybe yes. Or maybe not. Somebody would need to take a look.
Likely we could utilize some non-critical pieces. But surely the idea of using
OpenXT as a *basis* for Qubes OS is not a good idea.

I also feel obliged to protest slightly against singling out any single
individual as a central force which keeps the project going. First, this makes
disservice to many others (many of which enlisted on our always-lagging-behind
Team page, but some not recognized even there) who also have contributed to the
project. Sometimes under-recognized when looking at the git statistics.

Consider e.g. Rafał Wojtczuk, who implemented most of the GUI virtualization in
a way that it has not needed any modifications over the last 7 years... Yet,
many might be tempted to overlook this when counting commits. This is also
thanks to a reasonably good architecture of the GUI virtualization, I think,
another aspect that almost never shows itself in the log.

Also, we shall not forget about the mysterious forces in the universe who -- for
all these years -- have paid the salaries of the core team. It's quite likely
Qubes would have ceased to exist long ago, if not for these magical fairies ;)

In other words, Qubes should not be equated with any single person.

Speaking of good developers, I'd like to also share an observation that very
good and bright developers are often a source of troubles in security, and that
we should all, both developers and non-developers (e.g. researchers), be very
weary of that all the time.

This (surely controversial) paradox might be a result of the fact that being
developer -- in essence -- is about learning how to master complexity. Modern
languages and frameworks allows one, and in fact even encourage, to implement
ever more complex creations, almost always hiding all the complexity in the
shadow. (For example: to use D-Bus for communication between
differently-privileged domains[***])

But the complexity is still there. At the end of the day, whatever software we
write, it will finally get translated to the machine code and execute as such.

But enough bashing of developers :) Without developers (or devops) Qubes would
not have existed. Nor it would make sense without all the offensive security
expertise that have been invested into it, especially in the early days. And
this brings us back to where we started, i.e. the unique value of the project :)

Cheers,
joanna.

[*] For this reasons such system -- to be remotely meaningful -- must always
take great lengths to reduce cooperative covert channels.  Something that is
very hard on x86, and also something that Xen doesn't make easy to achieve.

[**] And thanks to this alternative approach, we're not so much interested in
elimination of cooperative covert channels in Qubes, although we recognize that
in some situations it would be still nice, such as for Tor/Whonix-related
services that run on top of Qubes infrastructure.

[***] A curious person might try to search the oss-security for all bugs
affecting D-bus and conclude there are not many. I think this is not surprising
given that D-bus is 1) primarily used on Linux Desktops (and AFAICT the Year of
Linux on the Desktop is still ahead of us), and 2) even if an attacker is
interested in attacking a Linux desktop, then usually -- thanks to the
monolithic architecture of mainstream Linux distributions -- it is not
necessarily for the attacker to attempt to attack D-Bus after she successfully
manages to execute her code as one of the user applications.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYc7QWAAoJEDOT2L8N3GcY1R4P/iz5+VY5u6bWPguAm+8ABNSn
uDJhCWC6IhbEysrGlCWoaZY0x9BZ+IB2zAVtu6wPn+dl2UOK72Ey6M4BX0GzYvsA
nXdfRGojQtPTLsh5czYilw/Kbgym8139Im424kCU73d6K1FkkXOZgOFgCD2OzydS
fpAjBz26WyEsZqZ0+iP9fy5A1O8TWiR9vhPLxtqMplBiTmR/iNnR1JIvGfRdL5LR
+LcTkDbzUmOYMACvB0VwRRTeO/q4z/bU/ztMRXoJAU/z2B65ABSDB5VkzysUPGUu
OYkCuMj6KnYeX2F6oA851ws30KXxXw/hGPSm/e7EHPjWJYA2mIzPyjxfTklU0imi
OdXlBx7sdTTn25khUKQ+ejSn4JeNC7yypOzNmquy+8Szz8k0YaPBkBy1b1/3IbaK
y1ioontNbKl/kxqkmcUiPmIDkkEeM1UhJDqdicP67xego48OuSb+ce65ggFAsE5q
i8VGE4OW5yIbOQ9w8yUJmjwlUKgjN0ZFajt6SeVNcKKhzhF9iRV775LocQuW6Mn2
x79/sDNrM1pdq4F6NooM3TnLYQh2fzKNH+PiDpQNJ/dBHnij4agl90eci/CU06j0
PGmK4qK5HzSfDJZ+LWSfusPq/apztcKRp5/AyMfTE0Y0JDZ3BkwfOowguvzh1ric
GrrFYVG4+LtndCFfb9Fa
=1zcp
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/20170109160231.GC14480%40work-mutt. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]