[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]