-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, Jan 23, 2018 at 07:12:23AM -0800, [email protected] 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 [email protected]. To post to this group, send email to [email protected]. 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.
