"Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dear Qubes Community,

Joanna Rutkowska has just published a new article titled "Qubes Air:
Generalizing the Qubes Architecture." The article is available both on
Joanna's blog:

https://blog.invisiblethings.org/2018/01/22/qubes-air.html

And on the Qubes website:

https://www.qubes-os.org/news/2018/01/22/qubes-air/

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpmBMEACgkQ203TvDlQ
MDC02A//Qjy5eAxiUSY6ZOlTQ6zDlilXtBTbSH4ig3Wa1DL9Jg3vHnR955LP9snP
40ZEIIc+cACis25g61SySbzkZUHXKW1cqfQCv/mjQAApWlFxQexIhX5WpS/u8RKB
PhNdgQVH+JYPOQZCidFAdkeSnBM+XFyxflPaCE1j1zisnTliH/Lwdl6xxEVht4nb
XglIZZz6D6PEQIouvM3qdsqi9DUY7Nc6AC5cLsI5NbVAcYtIVILxiSlxAM2OM/SL
k7rIoLnFGmgdmMJl5pInzy/b/SJvNmy70HjKRfg5y+EP9Wm024WaZQStacWmSfWa
x//plXVY/AuRWycyEtWLEdIhWNw4ZBV2CGkw72IxIN2SmJ+IfDA4N0fO81WZBJxo
gdH4Y/fkKZyUJ1/cKfttwt6jU8AOx8MZwmoh1tMjZbXuVPOoGgqBR0aXPAzAUcE2
5IpviczQZ0Ng9ZHyITZthiUO08nyqqJS8AH9UU4e2uDDq53TCXQa8pNzqgWtipY7
BkGwNY+PZaf3dAfYgEyAh+IFnHRI6e38Ej0pysHSGM386B4n19tmhEf9zLjXc+oU
2KUQJjOTp4ISfqNDYe3HpYsMR3RrqMWyMt3h4zG1gKPLhxAjAfdzVRq+Z0sBtJya
2begkIa7u91kJlta2/T4N6E2bqpe9tdAzsy/StqRBnnjIsRjYlE=
=y84I
-----END PGP SIGNATURE-----

[Kelly Dean]

Andrew David Wong writes:
> Joanna Rutkowska has just published a new article titled "Qubes Air:
> Generalizing the Qubes Architecture." The article is available both on
> Joanna's blog:
>
> https://blog.invisiblethings.org/2018/01/22/qubes-air.html
>
> And on the Qubes website:
>
> https://www.qubes-os.org/news/2018/01/22/qubes-air/

Instead of putting the RDP client into the master GUI qube to talk to the RDP server in the slave GUI qube, how about putting the RDP client into a stub qube in the master zone? The stub would work analogously to the Qubes PDF converter to produce simple image data. Then the master GUI qube can talk to the stub via the standard intra-zone GUI protocol, and an RDP exploit could only compromise the stub. Inter-slave compromises could also be prevented by using a dedicated stub for each slave, instead of one stub to talk to all the slaves.

[Kelly Dean]

Andrew David Wong writes:
> Joanna Rutkowska has just published a new article titled "Qubes Air:
> Generalizing the Qubes Architecture." The article is available both on
> Joanna's blog:
>
> https://blog.invisiblethings.org/2018/01/22/qubes-air.html
>
> And on the Qubes website:
>
> https://www.qubes-os.org/news/2018/01/22/qubes-air/

Qubes Air still has a master admin qube as a single point of failure. Qubes Air also makes the attacker's job easier, if he's trying to traverse from one VM to another within a slave zone in a system with heterogeneous VMMs, because he now has another VMM to choose from, with different vulnerabilities. He can either exploit the slave's VMM to gain control of the slave zone (including his target VM), or exploit the master zone's VMM to gain control of the entire system (including the slave's VMM). In contrast, a Qubes 4.0 system has only one VMM, so the attacker doesn't get a choice.

Qubes Air also doesn't really make deployment easier. If a user needs Qubes, that means he needs more security than a conventional OS gives. So, even in the easiest case (Qubes in a trusted cloud), his client device still at least needs an IOMMU-isolatable network device. Without that, the entire system is compromisable via the netvm, via merely an exploit of the network driver or stack, just like a conventional OS, so why would he bother running Qubes in the first place? But if his client device does have that feature, then the most practical OS to run on it is Qubes, so he's already going to have Qubes deployed before bothering with the cloud.

So then, what good is Qubes Air? Apparently, managing a cluster computer. But that's just an additional capability, after the user has already deployed and secured his Qubes system in the first place. Contrary to the news article, Qubes Air doesn't solve problems of initial deployment or single point of failure.

[Chris Laprise]

That was also how I understood the article, with my initial response here:

https://twitter.com/ttaskett/status/955540266479489024

I know that getting mired in the month-by-month compatibility issues is
a whole lot of No Fun, and that Qubes was meant to abstract-out hardware
details to some extent (use a whole OS -- pick one -- as a video or NIC
driver). But at some point the hardware will make or break us, and the
hardware we got now is Wintel; even Linux is an afterthought when you're
not looking at server components.

Even worse, Intel has quite illegally squeezed AMD out of the market,
leaving Qubes laptop buyers little choice but to wrestle with Intel
Skylake headaches. If AMD had more revenue available circa 2011, the
possible mobile APU choices later on could have offered a nice respite
for the Qubes community. (Intel still tries to avoid paying its EU
fines, and its CEO recently dumped all the stock he was legally
allowed....but I digress...)

Qubes' role appears to be taming unruly PC hardware, transforming it
into almost a different architecture through clever use of some of its
less common features. The Wintel hardware fights back, however, with
newer models (e.g. Skylake and later) refusing to work without trying
many new kernel iterations, etc. What Windows users feel as road bumps
are much more jarring to us.

But remember Microsoft isn't hardware agnostic. They have published
parameters for hardware design since the mid-1990s at least, and much of
what they write and/or certify is the result of close relationships with
hardware brands whose every product quirk is customized for Windows use.
MS has even reacted to the rough spots in their ecosystem by producing
their own PC systems.

There is one other consumer-friendly personal computer platform, Apple.
Are they hardware agnostic? :)

The next logical step seems to be in the description of open hardware
designs that will more faithfully serve Qubes' goal of strong and usable
endpoint security. It can be as simple as a list showing what qualities
a CPU, memory controller or keyboard can and cannot have, and the
minimum manifest of component types... to lay down the important
parameters that some hardware project (perhaps interested in the BOOM
processor, for example) might decide "we can do that".

In the meantime, our hardware compatibility situation isn't so terrible,
even with what the mere compatibility overlap that Xen's passthrough and
Linux drivers afford. Looked at another way, a Qubes user typically has
more models to choose from than any Mac user can claim. The dilemma is
whether we should keep finding them, or lay groundwork for building them.

-

PS - This isn't to imply that Qubes Air isn't worth pursuing. It reminds
me of a financialized BOINC: distributed computing and verification. But
currently I don't see how it can solve the user's local trust and
compatibility concerns, which serve as a foundation for all the rest.
Proponents in the age of the "Linux desktop" (circa 2004) used to claim
that Linux was a natural alternative to Windows despite hardware issues,
because apps were moving to the web... saying that if all you need is a
browser, then hardware = solved. It sure didn't turn out how they imagined.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Tom Zander]

On Tuesday, 23 January 2018 03:13:17 CET Kelly Dean wrote:
> If a user needs Qubes, that means he needs more security than a
> conventional OS gives.

I'd like to challange that assumption.

Following this assumption is like a self-fulfilling proficy; if you limit your
userbase to people that need "more security", you will limit your userbase
to a small group of people.

Aiming to be the best you can be for people that need more security is
great, and Qubes does that.
Being the best at that makes it likely to become good enough for a lot wider
group of people.

I would like that, aim to be the best for security minded people and support
efforts to make it available for everyone.

Naturally, my work on the qubes-controller to create a more usable user-
interface for everyone is following this thought.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

[Holger Levsen]

On Tue, Jan 23, 2018 at 02:47:30PM +0100, 'Tom Zander' via qubes-devel wrote:
> On Tuesday, 23 January 2018 03:13:17 CET Kelly Dean wrote:
> > If a user needs Qubes, that means he needs more security than a
> > conventional OS gives.
> I'd like to challange that assumption.

me too. Qubes is great if you just want an OS to develop and tinker,
without any security in mind. (disposable VMs and templates are sooo
use- and powerful.)

OTOH, Qubes is also great if you just want an OS to develop and tinker,
with security in mind.

:)


--
cheers,
Holger

[Tom Zander]

On Tuesday, 23 January 2018 05:56:05 CET Chris Laprise wrote:
> But at some point the hardware will make or break us, and the
> hardware we got now is Wintel; even Linux is an afterthought when you're
> not looking at server components.

I'm not sure if you guys caught the subtle side-effects of the 'Qubes-Air'
proposal. It didn't hit me until I slept on it.

Today there is a duopoly for CPUs and practically nobody considers ARM or
even smaller CPU makers. The main reason for this is the "bang-for-the-buck"
factor. To get a speedy desktop you need a fast CPU. The C stands for
"Central" for a reason.

Now should Qubes Air roll-out I can foresee building a desktop that is VERY
different from today.

Consider this;
I buy a simple piece of hardware (they mentioned a raspberry Pi for a
reason, I'm sure) as my main desktop which powers my graphics system and
thus my monitors.

I will want to add some more beefy qubes to this, and instead of buying one
very powerful CPU, I end up buying a series of cheaper "computers". I put
the word "computer" in quotes since I really only need a mainboard, memory
and a CPU plus some way to communicate to the main-qube (doesn't have to be
Ethernet).

Then for my C++ compilation I buy an ARM threadripper and plenty of memory.
On the other side of the scale I get for my 'Vault' VM a microcontroller
that only really has some sort of non-volatile memory and communication with
the main qube.
Be creative, use mini-itx PCs or any other such device, as long as it can
run python and xorg, you can turn it into another part of your desktop
computer.

So, what Kelly described Qubes Air as being good for;
"Apparently, managing a cluster computer"

I do agree, but I would argue that it is quite exciting as it effectively
removes the _central_ from CPU. And we have to admit that the majority of
the security issues we have today are with the CPU makers.

[awokd]

On Tue, January 23, 2018 2:05 pm, 'Tom Zander' via qubes-devel wrote:

>
> Now should Qubes Air roll-out I can foresee building a desktop that is
> VERY
> different from today.

I caught this too. No reason the cloud can't be on-prem and composed of
IoT devices.

[Ivan Mitev]

On 01/23/18 16:05, 'Tom Zander' via qubes-devel wrote:
> On Tuesday, 23 January 2018 05:56:05 CET Chris Laprise wrote:
>> But at some point the hardware will make or break us, and the
>> hardware we got now is Wintel; even Linux is an afterthought when you're
>> not looking at server components.
>
> I'm not sure if you guys caught the subtle side-effects of the 'Qubes-Air'
> proposal. It didn't hit me until I slept on it.

yep - the same thing occurred to me this morning after yesterday's post,
when I thought "hmm, they ended up drinking the cloud kool-aid like
everybody else"...

I don't think I'll ever use Qubes in the cloud as I'm often in places
where I can't rely on a good internet connection but being able to
locally and securely use different hardware platforms for different
workloads/usage opens a whole new world of use cases. (I liked the idea
of a dumb microcontroller for the vault VM).

One thing I'm not sure about though is how the "networked" qubes rpc
will be secured (attack surface of the tcp implementation and/or higher
protocols encapsulating rpc, ...).

Ivan

[Leo Gaspard]

On 01/23/2018 03:41 PM, Ivan Mitev wrote:> I don't think I'll ever use

Qubes in the cloud as I'm often in places
> where I can't rely on a good internet connection but being able to
> locally and securely use different hardware platforms for different
> workloads/usage opens a whole new world of use cases. (I liked the idea
> of a dumb microcontroller for the vault VM).

I think a dumb microcontroller for the vault VM only increases the
attack surface without any measurable benefit security-wise. Basically,
my reasoning is that if the Admin VM is compromised, then the vault is
compromised too anyway, so let's keep the vault as close as possible to
the Admin VM.

That said, running untrusted applications on hardware separate from the
trusted display/admin/vault hardware (including display as trusted here,
as I'm assuming a single-user non-company-laptop system where the GuiVM
gives full rights on the AdminVM) would be a great possibility, for
protecting those trusted systems against a number architectural attacks
from untrusted applications. And even segregating different untrusted
applications on different hardware, in the same way as qubes allows it
currently, would be great too!

[bow...@gmail.com]

On Tuesday, 23 January 2018 14:44:21 UTC, Ivan Mitev wrote:
> On 01/23/18 16:05, 'Tom Zander' via qubes-devel wrote:
> > On Tuesday, 23 January 2018 05:56:05 CET Chris Laprise wrote:
> >> But at some point the hardware will make or break us, and the
> >> hardware we got now is Wintel; even Linux is an afterthought when you're
> >> not looking at server components.
> >
> > I'm not sure if you guys caught the subtle side-effects of the 'Qubes-Air'
> > proposal. It didn't hit me until I slept on it.
>
> yep - the same thing occurred to me this morning after yesterday's post,
> when I thought "hmm, they ended up drinking the cloud kool-aid like
> everybody else"...
>
> I don't think I'll ever use Qubes in the cloud as I'm often in places
> where I can't rely on a good internet connection but being able to
> locally and securely use different hardware platforms for different
> workloads/usage opens a whole new world of use cases. (I liked the idea
> of a dumb microcontroller for the vault VM).

You however may want to use cloud services. I.e. a great one like Office 265
and have a VM on Azure to host the browser that connect to it... with the display streamed back home securely (and I agree with your question just below).

[Joanna Rutkowska]

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

I'm glad you guys also see the many opportunities that Qubes Air opens
up in front of us now :)

Cheers,
joanna.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJaZ1F/AAoJEDOT2L8N3GcYD1YP+wT/HOpIAiDrdZfK/SBUqcDD
rGdvxCuB3Zf+43BJ2v/ubjKaHLQ8nfwwabh+Ou6Yqrlff+m1dUibMsqxbszRCUbB
OXcpBO+vFS6d50LA50huea4Xq7rHL08FA/eNVGruan8xhtRFaOqop/SRtc/UAhMg
qlpbEcGsDInfPKg66Cusc6vzpy/DUYUfLE0cHyIxdIBCkwnpfej6D9yRF49HBr2H
gEDS8KM/15aAIXYsdmChP1wayLCttd2uAfBEuvEwyX7HfE7zbnhj+CsFBA/7OPPg
1uHrZmEP0T++WGTomxAz9dUsXs7zh8vQ0ZXhKELZSJ0RKZu9mmcsG22ZaOySdiCH
O//gb09VkEiHOZSa+l2YVYiLn3QyZFO7WMm/bPAiQ/f2lS+QzkY4WAXgI9zITE54
SdHToWACBfkHo0e+TD2Vu5l+FQrLPK8UhB2+LYNGbsTomKeMRvZQ2tJadzR67uSI
GWDDYbBw3grnjj3Fd5vVGbNc+32Kywald+vyXvrhH8QHnmGze2ogeTcUlRrS7GV/
Q4rjMGIrZGjlxEgmnP8Fbrw+MPtvGOoIjwg98h9ZE0/Nof4S0FfNbWjoiGlDdc8m
LWlSJpSsWVuqVmCoo31FfOyvZKi4Tiwg5UPlmG/jc8gDH8lvU8q7rlqJDkeYtt6j
QjMARk9d5N/Hy4YYJg8X
=h2tA
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Tue, Jan 23, 2018 at 07:12:23AM -0800, bow...@gmail.com wrote:
> On Tuesday, 23 January 2018 14:44:21 UTC, Ivan Mitev wrote:
> > On 01/23/18 16:05, 'Tom Zander' via qubes-devel wrote:
> > > On Tuesday, 23 January 2018 05:56:05 CET Chris Laprise wrote:
> > >> But at some point the hardware will make or break us, and the
> > >> hardware we got now is Wintel; even Linux is an afterthought when you're
> > >> not looking at server components.
> > >
> > > I'm not sure if you guys caught the subtle side-effects of the 'Qubes-Air'
> > > proposal. It didn't hit me until I slept on it.
> >
> > yep - the same thing occurred to me this morning after yesterday's post,
> > when I thought "hmm, they ended up drinking the cloud kool-aid like
> > everybody else"...
> >
> > I don't think I'll ever use Qubes in the cloud as I'm often in places
> > where I can't rely on a good internet connection but being able to
> > locally and securely use different hardware platforms for different
> > workloads/usage opens a whole new world of use cases. (I liked the idea
> > of a dumb microcontroller for the vault VM).
>
> You however may want to use cloud services. I.e. a great one like Office 265
> and have a VM on Azure to host the browser that connect to it... with
> the display streamed back home securely (and I agree with your
> question just below).

Yes, this is one use case - run untrusted applications somewhere far
from your trusted hardware, so even bugs in hypervisor and/or hardware
will not allow that application break into your trusted machine.

One may want to do this not only for security, but also for convenience
- - carry a small personal (trusted) device, while still use powerful
resources of some remote (less trusted) machine. This is of course
possible right now with different technologies already, but having it
integrated into Qubes may be even more convenient.

But there is also another case - use separate hardware (or whole zones)
for specific, trusted applications. For example one may design Split GPG
on separate device that way it will not be possible to extract secret
keys even after breaking into Admin VM. A qube may simply not expose any
qrexec service for that.

Something very similar can already be done on USB Armory:
https://github.com/inversepath/usbarmory/blob/master/software/buildroot/README-Qubes_Split_GPG.md
You just need to lock out full ssh access and expose only gpg-related
services.

Split GPG is just one example of such scenario, but there surely will be
many more.

Also, applying different zones for different stuff, allows better,
independent auditing. Although this is more useful for corporate
scenarios, not personal ones.

> > One thing I'm not sure about though is how the "networked" qubes rpc
> > will be secured (attack surface of the tcp implementation and/or higher
> > protocols encapsulating rpc, ...).

Yes, this is one of things we need to carefully design and implement.
Some preliminary ideas include stripping network layer (IP, TCP) in
sys-net, and pass raw encrypted & authenticated data stream to separate
VM over channel. Then decrypt it there. The "encrypted & authenticated"
is also not an easy concept, lets avoid heartbleed.
So, a long way before Qubes Air will become a reality.

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpnVaMACgkQ24/THMrX
1yy9tgf/TEXAWw071LbS7/1R+X6aDEgSoj5P3xvPU6NpGHbBd4ZOKZfr271AArke
QkZfo37kUp1CVLWFEg44j/t8Tj8w9wbPofpFD5HyzBA5jwDlR8mYt3Bf5fImRF3k
MuPjIGUYUWtWKtBkxttHS9k0es3DBNzT0rdmcfBoITSvYrd4dwUTMqZXibzlB3aL
27bIajeLYRaB7sOv+0yH7+lwArAq9bHB0+4VXQInXNNrOXR//TPGbyLH3f/Upb0f
8P6d7RpDi6V30bWH9NHtyxQ5rnkbyFpeE0A41d/3wjubBAkTL0ulT0C1Q8u7k8RF
giW04WGRj2zKw/nmNAUoASC88ZfvGw==
=Y3S9
-----END PGP SIGNATURE-----

[Chris Laprise]

On 01/23/2018 10:15 AM, Joanna Rutkowska wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Tue, Jan 23, 2018 at 02:35:45PM -0000, awokd wrote:
>> On Tue, January 23, 2018 2:05 pm, 'Tom Zander' via qubes-devel wrote:
>>
>>>
>>> Now should Qubes Air roll-out I can foresee building a desktop that is
>>> VERY
>>> different from today.
>>
>> I caught this too. No reason the cloud can't be on-prem and composed of
>> IoT devices.
>>
>
> I'm glad you guys also see the many opportunities that Qubes Air opens
> up in front of us now :)

The opportunities that golem espouses aren't at issue.

Its just this implication in the article that distributed computing will
solve PC compatibility problems. The emergence of web apps didn't
accomplish this, so I think it stands to reason that golem won't either.

[Derek Fawcus]

On Tue, Jan 23, 2018 at 03:05:13PM +0100, 'Tom Zander' via qubes-devel wrote:
> I buy a simple piece of hardware (they mentioned a raspberry Pi for a
> reason, I'm sure) as my main desktop which powers my graphics system and
> thus my monitors.
>
> I will want to add some more beefy qubes to this, and instead of buying one
> very powerful CPU, I end up buying a series of cheaper "computers". I put
> the word "computer" in quotes since I really only need a mainboard, memory
> and a CPU plus some way to communicate to the main-qube (doesn't have to be
> Ethernet).
>
> Then for my C++ compilation I buy an ARM threadripper and plenty of memory.

cf plan9: terminal machines and cpu servers.

DF

[Joseph Taylor]

> But there is also another case - use separate hardware (or whole zones)
> for specific, trusted applications.

The first thing I thought of when the idea of using RPi was mentioned was using an RPi for a USB host, on systems where there's only one USB controller so you can't separate the IO from untrusted USB devices. Qubes Air would let you deploy a secondary usbvm to a RPi to host untrusted USB devices.

> Yes, this is one of things we need to carefully design and implement.
> Some preliminary ideas include stripping network layer (IP, TCP) in
> sys-net, and pass raw encrypted & authenticated data stream to separate
> VM over channel. Then decrypt it there. The "encrypted & authenticated"
> is also not an easy concept, lets avoid heartbleed.
> So, a long way before Qubes Air will become a reality.

IMO this is quite easy, the solution has even already been implemented - just host the RDP client in a dedicated VM. The same solution being used to host Windows 10 VMs on Qubes as described here: groups.google.com/forum/#!topic/qubes-users/dB_OU87dJWA
You could even potentially strip down the VM so it only has the bare minimum software to host a basic RDP server to reduce overhead.