Re: [qubes-users] Virtualization in the cloud
On 06/17/2017 04:14 PM, Chris Laprise wrote: Normally, ownership = control over whichever keys are used by the CPU. Something called Intel SGX could change that: http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html Note, this is a desktop PC-focused list so is not the best place to ask about the dynamics of server/cloud security. FYI: SGX is simply another ME technology that removes user control, it was created for hollywoods latest BluRay 4K DRM scheme. http://www.businesswire.com/news/home/20170425005930/en/CyberLink-Enable-World%E2%80%99s-Ultra-HD-Blu-Ray-Software -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a20a83f3-02d2-cb86-2772-68a3f8ec3706%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Virtualization in the cloud
On 06/17/2017 10:04 AM, iamrootyr...@gmail.com wrote: I was just wondering. Is it possible to get a VM on Google Cloud Compute (for e.g.) and be able to mitigate the security issues caused by not being the owner of the metal/hypervisor. If, say, you run an https enabled apache instance, the ease of creation/setup, ability to later scale and redundancy are all nice. But Google have access to your ssl key contained within the virtual drive. You could use LUKS with full system encryption but I'm not sure this helps. They could snapshot a running instance (post LUKS pw challenge) and respin the VM in that state. They could also modify the hypervisor to add a keylogger to the virtualised keyboard input interface to capture the LUKS password. They could also simply lift the key from the VM's RAM (Evil Maid in the cloud?). So the real question is .. could Qubes run in an AWS/Azure/Google instance and it's assumptions of everything being permanently comprimised withstand even the hypervisor being untrustworthy? Or do you have to ultimately not only trust the hypervisor but also be the owner of it and the hardware? Is there ANY way to maintain security in the cloud or if you care about security should you simply avoid cloud-hosting altogether and do it in-house? Lots of people seem to do it, maybe they've just accepted the risk. Normally, ownership = control over whichever keys are used by the CPU. Something called Intel SGX could change that: http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html Note, this is a desktop PC-focused list so is not the best place to ask about the dynamics of server/cloud security. -- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/887ebfd6-7023-46d3-dc56-56d3ce5bfe9a%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Virtualization in the cloud
I'm of the opinion that if "everybody's doing it" then it's probably best to take a different approach;. I don't trust or play around with the cloud, especially with a behemoth like Google. Color me paranoid. Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Message Subject: [qubes-users] Virtualization in the cloud Local Time: June 17, 2017 2:04 PM UTC Time: June 17, 2017 2:04 PM From: iamrootyr...@gmail.com To: qubes-users I was just wondering. Is it possible to get a VM on Google Cloud Compute (for e.g.) and be able to mitigate the security issues caused by not being the owner of the metal/hypervisor. If, say, you run an https enabled apache instance, the ease of creation/setup, ability to later scale and redundancy are all nice. But Google have access to your ssl key contained within the virtual drive. You could use LUKS with full system encryption but I"m not sure this helps. They could snapshot a running instance (post LUKS pw challenge) and respin the VM in that state. They could also modify the hypervisor to add a keylogger to the virtualised keyboard input interface to capture the LUKS password. They could also simply lift the key from the VM"s RAM (Evil Maid in the cloud?). So the real question is .. could Qubes run in an AWS/Azure/Google instance and it"s assumptions of everything being permanently comprimised withstand even the hypervisor being untrustworthy? Or do you have to ultimately not only trust the hypervisor but also be the owner of it and the hardware? Is there ANY way to maintain security in the cloud or if you care about security should you simply avoid cloud-hosting altogether and do it in-house? Lots of people seem to do it, maybe they"ve just accepted the risk. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8f94ba97-cc72-44d6-a065-7171b707e00a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/_kHSBQKb9x7PnAuVK7BuZVO8vlu_bQgiRNo14axMllsIVcLAANsw8aVPj9_09CDiNPfAaS0BrxdkhJ0fqVjWb7Bo9Y6v1betHghk-U8ydJo%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
