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

List:       qubes-devel
Subject:    Re: [qubes-devel] Qubes + OpenXT
From:       Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek () invisiblethingslab ! com>
Date:       2017-01-20 12:18:29
Message-ID: 20170120121829.GD5268 () mail-itl
[Download RAW message or body]

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

On Wed, Jan 18, 2017 at 09:12:49PM -0800, Eric Shelton wrote:
> On Monday, January 9, 2017 at 11:02:41 AM UTC-5, Joanna Rutkowska wrote:
> > 
> > ...
> > 
> > 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. 
> > 
> 
> I suppose the extent to which such issues would be a liability for OpenXT 
> (or certain parts of it) serving as a base for Qubes depends on what is 
> being used, how it is incorporated into Qubes, and whether trust can be 
> invested in the parts that are used.  For example, like Qubes, OpenXT 
> maintains a number of patches applied against upstream Xen.  Perhaps Qubes 
> might use the same hypervisor, if those patches were considered auditable. 
> Additionally, as a downstream project, Qubes could pick and choose from 
> the OpenXT patches and apply additional ones, if needed.

The reason pointed out by Joanna is exactly why we shouldn't blindly
import components from this project, even if they've solved a problem we
have. Instead if doing so, we should carefully analyse how they've
designed it and implemented and only then consider basing on it.

(...)

> > 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).[**] 
> > 
> 
> I'm not convinced that a Qubes built on top of or using OpenXT components 
> requires buying in to the MLS approach.  You can use the same hypervisor 
> and other components - just use them differently.
> 
> What could be beneficial for Qubes is not so much building it "on top of 
> OpenXT" or adopting the OpenXT architecture as it is identifying software 
> components might be packaged up in a way that they could be effectively 
> shared and maintained across both projects.  Stepping back and looking at 
> the two projects from a 30,000 foot view, there are a fair number of things 
> in common that might somehow be packaged up for common code across the 
> projects.  Things such as:
> - measured boot (including extending measured boot to VMs)

This is something we could consider, but I think currently there are
better implementations, for example AEM2 Turbo Edition [1] or Heads[2].

[1] http://mjg59.dreamwidth.org/35742.html
[2] https://github.com/osresearch/heads

> - improvements/fixes to upstream Xen (OpenXT is exploring disabling 
> unnecessary Xen features - https://openxt.atlassian.net/browse/OXT-839 - 
> something that I think the Qubes dev team would also like to be doing with 
> Xen to remove bells and whistles like nested HVM)

Actually, we already use it in Xen 4.7/4.8 branches for Qubes 4.0.

> - patches to the Linux kernel (keeping up with new kernels)

This, and patched Xen is something we already do to some extend. But for
both projects I try to send as much as possible to upstream. Especially
for new patches. There is a backlog of Xen patches which are currently
quite Qubes-specific (and purposely breaking non-Qubes use cases), so
those needs some work to be more generic. But we have some progress
here. I believe OpenXT have very similar approach, so in this area in
practice we do share work.

> - "modern" stubdomains (based on upstream QEMU, rather than QEMU 1.2 or so)

As noted previously, HW42 is working on this and in fact mostly
finished. Similar to above - there are some aspects of OpenXT we can
reuse and we do. But there are also significant differences (transport
channel for qmp, different gui-agent, and some more), which makes it
impossible (and undesirable) to reuse as is.

> - PCI passthrough (their users want this feature too, including GPU 
> passthrough)
> - solid Windows guest support (a fair number of users need/want this. 
> Qubes still has no solution for sound in Windows, but OpenXT does)

Actually, I don't really understand what this means. My understanding is
that OpenXT integration level is much much lower (very few inter-VM
services etc). So "solid support for Windows" really means "it's
possible to boot Windows". Which is also possible on Qubes OS.

As for sound support, it's mostly about having sound proxy in
stubdomain. Which indeed is something we could try to import. The Qemu
patch is very OpenXT-specific, but maybe some parts could be reused.

> - a build framework (The Qubes build system is "unique."  Will it be the 
> desired long term approach?)

Take a look at explanation why we still have our own qubes-builder[3]. The
actual package build is very similar to what particular upstream project
use (dpkg-buildpackage, rpmbuild, etc). It is possible to build Qubes
packages using just those tools - assuming you've setup build
environment (installed build dependencies etc). Each distribution have
also some higher level tool to take care of it (mock for Fedora, sbuild
for Debian etc). And actually we're in the process of using those tools
to install build dependencies, instead of our own scripts.

But the main purpose of qubes-builder still stands - download _and
verify_ the code. Something that most of similar tools are doing
partially (for example checking signature/hash only if some is
configured - and failing only when it's invalid, but not when it's
missing).

Actually, I have checked OpenEmbedded (used by OpenXT) in the past, and
concluded it would be tricky to make sure that the build framework
itself would not do careless "curl | bash" equivalent (disguised as
"wget; tar; cd; make"). And also OpenEmbedded is targeting, as the name
suggests, embedded platforms, where the artifact is a whole system
(firmware) image. Not individual packages. Something that could work for
stubdomain for example but probably none of other Qubes parts. And in
fact there are very few projects able to work with different package
types and at the same time handle multiple source components (with
reasonable security).

[3] https://www.qubes-os.org/news/2016/05/30/build-security/

(...)

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYggAWAAoJENuP0xzK19cs41IH/j4JUNkFs0VWPL8SoEtapXL8
p8qGc1tPOArolPT9yV+yabker4Ul7SCepri6ExOeQvuip2xaEbf6aWhc2Qmz2ybF
5Mg/N5ToS41Tt3L2bXSbU0wW3Cf3DzkhNhRly/v5SJkufVXnUpNQkIcqiD+hN1tM
tQTxprc/C/e7QYol4AIBoSL1mw5FvFU9ebxb+DlDwsxkGiqc+g7Q8C0Ug6VUgr8J
67VSn4KI5rJcKIUwZxBe4/YofW6nZZ8zqJ6/oynAn9fXO8cCI9cpfTRKHjq+SYJH
YV5HjLlGDtKvVXcw+K6VFHkqMBhEHAU+0jzSmXQCuRcodMKiDLsUvPEstAz72jA=
=ND0v
-----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/20170120121829.GD5268%40mail-itl. For \
more options, visit https://groups.google.com/d/optout.


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