From qubes-devel Mon Jan 09 16:02:32 2017 From: Joanna Rutkowska Date: Mon, 09 Jan 2017 16:02:32 +0000 To: qubes-devel Subject: Re: [qubes-devel] Qubes + OpenXT Message-Id: <20170109160231.GC14480 () work-mutt> X-MARC-Message: https://marc.info/?l=qubes-devel&m=148397776112090 -----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 projec= t: > - The recent announcements about Qubes' funding and shift in development= =20 > priorities. It is great to hear that Qubes will remain an open source=20 > effort. However, there has consistently only been a small handful of=20 > developers active in Qubes -- mainly those being paid by ITL (without=20 > Marek, I don't think there would be a Qubes today). With their prioritie= s=20 > being set by commercial clients, it seems less certain what Qubes will=20 > focus on, and on what schedule they will get there. I suppose there just= =20 > aren't all that many non-ITL open source contributors with the needed Lin= ux=20 > internals and Xen internals expertise looking to chip in, and maybe this= =20 > situation will not change anytime soon. > - It came to my attention that OpenXT has implemented Linux-based=20 > stubdomains using upstream QEMU - an issue long neglected by upstream Xen= .=20 > Qubes is working on this, and maybe it will be a 4.0 feature. >=20 > A couple of quick summaries of the OpenXT effort: > http://www.slideshare.net/xen_com_mgr/the-openxt-project-in-2016-christop= her-clark-bae-systems > http://www.slideshare.net/xen_com_mgr/tricca-xen-summit2014 >=20 > 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 >=20 > I believe I am reasonably familiar with the Qubes project, and to me ther= e=20 > seems to be a significant amount of overlap in the missions and solutions= =20 > of Qubes and OpenXT - especially where it counts: the "security research"= =20 > and virtual desktop integration areas. This also translates into a lot o= f=20 > duplicated effort across these two projects. OpenXT has their own=20 > TPM/AEM/measured launch, PV-USB (implemented long ago, and with Windows= =20 > support), stub domains (they have long used Linux-based stubdomains, and= =20 > will be moving up to QEMU 2.6 soon), netvm, and a UIVM that has been=20 > separated from dom0. I'm not saying everything is a one-to-one match wit= h=20 > the Qubes architecture, but I can say that Qubes has been, and continues= =20 > to, spend its precious and limited resources implementing and updating=20 > features that are already implemented and being updated in OpenXT. Also,= =20 > OpenXT is way ahead of Qubes on Windows guest support (which I suspect is= =20 > important for the Qubes commercialization path). There are also many ide= as=20 > implemented or being worked on in Qubes that strike me as positive=20 > improvements for OpenXT: usbvm, seamless desktop, template domains, etc. >=20 > Perhaps it is worth considering (or reconsidering?) bringing the efforts = of=20 > these two projects together. OpenXT might offer a reasonable base=20 > architecture for Qubes, and allow the Qubes team to not spread itself so= =20 > thin (Marek and company are tackling problems from the BIOS on up, and th= at=20 > presents a lots of software that is changing (changes in KDE broke the=20 > window decoration, Wayland in F25 will surely bring new headaches) and=20 > constantly is pulling the Qubes developers away from their core mission.= =20 > In some ways, isn't this what the HAL effort (which unfortunately does n= ot=20 > seen to have achieved much) was about - abstracting Qubes away from the= =20 > base hypervisor architecture? >=20 > The only comment I have seen from the Qubes developers about OpenXT is=20 > criticism of their use of dbus in their interdomain communication=20 > architecture (https://twitter.com/rootkovska/status/505024924097196032). = I=20 > imagine the Qubes team can find a reasonable way around that. I understa= nd=20 > there is going to be a significant "not invented here" resistance to this= =20 > idea, but keep in mind that there are at least as many smart and security= =20 > conscious developers working on OpenXT, too. >=20 > Perhaps another issue is that the developers working on OpenXT, for the= =20 > most part, work for US defense industry contractors. SecureView appears = to=20 > have ties with the NSA and the US Air Force. On the other hand, I will= =20 > point out that these same parties are also contributors to upstream Xen a= nd=20 > Linux - although among many others (and hypothetically, many more "sets o= f=20 > eyes" - however well that concept actually works in practice). Plus,=20 > somehow people long ago rationalized Tor having arisen from US Naval=20 > Research Laboratory and receiving ongoing funding from the US government.= =20 > For what it is worth, Qubes could be a viable competitor for SecureView= =20 > (especially if built on OpenXT), if you want to pursue that avenue for=20 > commercial funding. >=20 > I love Qubes, and it would be great if it had loads of resources to=20 > continue to do everything from the bottom to the top and remain the=20 > somewhat independent effort it has been for the last couple of years. Bu= t=20 > that is not the case, is it? If building Qubes on top of OpenXT allows= =20 > Qubes developers to focus on the unique aspects of Qubes instead of fixin= g=20 > up things being broken by other projects, that would allow Qubes develope= r=20 > hours to be focused on developing the aspects that are unique to Qubes,= =20 > demonstrate the value of Qubes, and perhaps establish a more sustainable= =20 > cycle for Qubes (user interest, commercial interest, developer interest,= =20 > etc.) that better ensures the project can continue. Plus, I suspect both= =20 > projects have a lot to gain from each other. Frankly, otherwise I fear= =20 > that the Qubes project will, despite the team's best intentions and=20 > efforts, fizzle out over the next few years. >=20 > Best, > Eric >=20 You've touched on an interesting topic: what's the unique value of the Qube= s 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 o= ne hand ("let's rewrite the whole stack from scratch"), and "conformism" on th= e 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 philoso= phy 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 potentiall= y 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 s= ee 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 graph= ics virtualization technology. While I'm sure that the word "pass-through" brings very positive connotatio= ns to most readers ("something that doesn't require much handling from the hyperv= isor 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 i= f 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 emul= ation code? On more recent Intel GPUs the situation has presumably improved, but the fa= ct 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 w= hich can get full pass-through access to the GPU. In Qubes, the GUI domain is pl= aned to be *the only one* VM granted pass-through access to the GPU, while we wo= uld continue to be using our -- I believe -- very secure GUI virtualization pro= tocol 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 i= n 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 al= l, what's the point of running a few monolithic Windows VMs, if each of them i= s still... a buggy, monolithic VM which can get compromised just as easily? O= f course, the official ideology of MLS says that even if an attacker compromi= ses one of the VMs, then they would not be able to at least leak the data to ot= her, unclassified networks.[*] In any case, the MLS proponents believe that thes= e 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 promot= e this security model (and incidentally also XT and SELinux)... ;) Contract this to the Qubes approach, where we would like to utilize multipl= e domains in order to actually make the domains more difficult to attack. Whe= ther by making them "disposable", or by splitting the tasks between more than on= e 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 t= hat for a project like Qubes the proper architecture is something that should a= lways come first. Or to stay it differently: even the best code cannot be "rescue= d" 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 us= ing 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 ma= kes disservice to many others (many of which enlisted on our always-lagging-beh= ind 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=C5=82 Wojtczuk, who implemented most of the GUI virtuali= zation 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 like= ly 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 ver= y 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 ve= ry weary of that all the time. This (surely controversial) paradox might be a result of the fact that bein= g developer -- in essence -- is about learning how to master complexity. Mode= rn languages and frameworks allows one, and in fact even encourage, to impleme= nt 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 su= ch. But enough bashing of developers :) Without developers (or devops) Qubes wo= uld not have existed. Nor it would make sense without all the offensive securit= y expertise that have been invested into it, especially in the early days. An= d this brings us back to where we started, i.e. the unique value of the proje= ct :) Cheers, joanna. [*] For this reasons such system -- to be remotely meaningful -- must alway= s take great lengths to reduce cooperative covert channels. Something that i= s 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 surpri= sing given that D-bus is 1) primarily used on Linux Desktops (and AFAICT the Yea= r 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 successfu= lly 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 =3D1zcp -----END PGP SIGNATURE----- --=20 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 e= mail 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.