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

List:       qubes-devel
Subject:    Re: [qubes-devel] Qubes Air's usefulness
From:       Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek () invisiblethingslab ! com>
Date:       2018-01-23 15:32:51
Message-ID: 20180123153251.GK2653 () mail-itl
[Download RAW message or body]

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

On Tue, Jan 23, 2018 at 07:12:23AM -0800, bowabos@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-----

-- 
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/20180123153251.GK2653%40mail-itl. For \
more options, visit https://groups.google.com/d/optout.


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