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

[Alex Dubois]

As always fantastic article and work by your team.

One point about the RDP security concerns... You could have (if 2 zones and 4 VM in each):
2x4x AppVM --> 2x4x CouldGUI+RDPd --------> 2x4x RDPc+DesktopGUI --> 1 QubesGUI

--> local fast secure UI
---------------> compressed stream (RDP or other)

You could possible have 2x RDPc+DesktopGUI (one per zone if this is your security/performance model).

One point about Application as a service: I agree about browser isolation not being able to secure users (and certainly not able to manage privacy).
Let's just ignore user isolation in Office265 ;-)

Looking forward to what will come out. Devil is in the details.

[Andrew Clausen]

Hi all,

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/

I confess I found the writing a bit difficult to understand this time.  I suggest adding some more example use cases.

Consider the following use case -- is this what Joanna had in mind?

Suppose you are a journalist, and you have received a PDF document on a USB stick from an anonymous source.  Given all the recent meltdown/rowhammer/spectre/xen debacles, you aren't thrilled about plugging in the USB stick into your Qubes laptop.  And even if you did plug it in, you wouldn't be thrilled about running the Qubes PDF converter on it either.

So what do you do?

On the USB front, you might buy a Raspberry Pi, and plug the USB stick into that instead.  You could then scp the PDF document from the Rasbperry Pi onto the Qubes laptop.  Qubes Air would make this easier by making using the Raspberry Pi appear just like another USB VM (like sys-usb).

You could also do the PDF conversion on the same Raspberry Pi (specifically the half of the conversion that would normally run inside a disposable VM).  Qubes Air would also make this work smoothly, as if the disposable VM were running on the Qubes laptop.

So, what are the security trade-offs?

First, this Raspberry Pi arrangement means that both steps are better isolated from the Qubes laptop.  Previously, a successful attack on the sys-usb VM or the disposable VM could be escalated via Meltdown et al to take over the whole laptop.  Now they can't.

Second, the Raspberry Pi has inferior isolation within itself (e.g. no IOMMU).  This means that if the journalist re-uses the same Raspberry Pi for several different sources, those sources could interfere with each other.  For instance, if source A is malicious, it could reprogram the Raspberry Pi to destroy all data from source B.

Are you hoping that Qubes Air could overcome this obstacle?  For example, are you hoping that a dedicated Raspberry Pi just for disposable VMs would be able to isolate all disposable VMs from each other?

Kind regards,

Andrew

[Alex Dubois]

My understanding is that this paper did not explore this type of exposure. It is mainly focused on GUI "remoting" and compute "remoting".

The risk you exposed with the USB front-end and the lack of compartmentalization are a problem you are right. So the right way is still to put the USB stick in the laptop, however the USB VM would run in the RaspberryPi (a FileSystem "remoting" would be required). And for example the decryption of the docs in the USBVM would be protected from shared CPU cache types of attacks. This is my understanding...

[Syd Brisby]

some considerations:

* Raspberry Pi, beagleboard, USB armory, etc are very low-powered devices (in both CPU & RAM). So running Qubes software on them at a productive speed will be a challenge.

* You're saying that laptop hardware specs are a problem for users. But remember we had the problem of wireless modules still broadcasting after being turned "off". So we needed laptops with wireless hardware switches to be more certain that we couldn't be hacked. But now you are asking us to again trust ordinary laptops and tablets that may not have hardware switches.

* In reality, you are also changing from "deployment and virtualization" as a single point of failure to "wireless" as the single point of failure. For example, WPA2 has been declared insecure (hackable), with WPA3 being necessary as a replacement. But, amazingly, WPA2 is still being "patched" by manufacturers who think it's still acceptable - so how long will it take for WPA3 to become ubiquitous?

[Alex Dubois]

On Wednesday, 24 January 2018 04:30:08 UTC, Syd Brisby wrote:
> some considerations:
>
> * Raspberry Pi, beagleboard, USB armory, etc are very low-powered devices (in both CPU & RAM). So running Qubes software on them at a productive speed will be a challenge.

Perfectly fine as a USB decryptionVM or as a Split PGP with the benefit of not have your keys in CPU cache.

>
> * You're saying that laptop hardware specs are a problem for users. But remember we had the problem of wireless modules still broadcasting after being turned "off". So we needed laptops with wireless hardware switches to be more certain that we couldn't be hacked. But now you are asking us to again trust ordinary laptops and tablets that may not have hardware switches.
>
> * In reality, you are also changing from "deployment and virtualization" as a single point of failure to "wireless" as the single point of failure. For example, WPA2 has been declared insecure (hackable), with WPA3 being necessary as a replacement. But, amazingly, WPA2 is still being "patched" by manufacturers who think it's still acceptable - so how long will it take for WPA3 to become ubiquitous?

On the Raspberry side, wireless is a no go. Secure wired connection will be required (to mitigate L2 and below attacks).

On the laptop side, sys-net will mitigate L2 and lower attacks. so your GUI connect to your QubesAIR by connecting to sys-firewall... nothing is changing (with the assumption that the protocol for remoting between Qubes is secure).

[Vít Šesták]

Raspberry Pi as a DVM is not that easy, but it is probably possible:

1. Let's have an image for the "VM" in your laptop.
2. Insert a SD card to the laptop and dd the image.
3. Boot Raspberry Pi.

This assumes that:

* You perform this every time you want a clean state.
* Raspberry Pi has no persistent storage outside of the SD card.
* MicroSD card cannot be hacked (e.g., Raspberry Pi cannot overwrite the firmware).
* Your laptop is not configured to parse anything from the card. (If it is not that case, it could try to compromise your laptop.)

Regards,
Vít Šesták 'v6ak'