openstack team mailing list archive
Mailing list archive
Re: Encrypted virtual machines
Functionally if the scheduler doesn't know what it's passing to the
CPU or into paging memory a lot of optimization possibilities go out
the window. If it does know one can infer a great deal about your
datasets protected or not.
On Thu, Apr 26, 2012 at 3:08 PM, Justin Santa Barbara
> I think that Intel's trusted cloud work is trying to solve that exact
> compute host problem. It may already have the framework to do so even if
> the software hasn't caught up (i.e. if we still have some work to do!)
> It relies on a TPM chip, all code is measured before being run, and then
> there's a protocol to prove that a system is running that code (remote
> attestation). If you change the software stack by introducing a sniffer,
> you change the hash. So we'd need a stack with no root-access / back-doors.
> Once a back-door becomes known, the hash should no longer be trusted.
> I'm by no means an expert (I'm still learning about it), but I believe it is
> possible, having read this
> paper: http://www.research.ibm.com/trl/projects/watc/FredericStumpfPaper.pdf
> I'm sure there are still exploits (hardware RAM taps?), and we rely on a
> total code audit, but we can raise the bar a long way.
> Anyone from Intel / familiar with Intel's trusted cloud work want to explain
> better than I can?
> On Thu, Apr 26, 2012 at 1:44 PM, Matt Joyce <matt@xxxxxxxxxxxxxxx> wrote:
>> As far as storage is concerned, certainly a cloud storage environment
>> could be leveraged to store pre-encrypted data in such a way that
>> would make it difficult bordering on impossible to seize or access
>> without the consent of the owner.
>> As far as compute hosts are concerned, it is a whole different matter.
>> For the foreseeable future ( barring the invention of new widely
>> distributed in CPU technology ) . Anyone with ring 0 execution access
>> on a system ( ie root / sudo ) will be able to pull data from a
>> running instance pretty much no matter what you do.
>> You can certainly raise the bar on difficulty there, but the
>> fundamental path of sniffing schedulers / paging memory / etc will be
>> there for a fairly long time. Even trusted computing wouldn't be
>> applicable to protecting a vm's scheduler from the hypervisors owner.
>> So, I think functionally it should be assumed that a provider will be
>> able to access anything that you access on a hosted VM. As far as a
>> trust relationship goes in elastic computing, there must be an
>> implicit trust of the cloud provider. And as with any trust
>> relationship there is always going to be an element of risk.
>> On Thu, Apr 26, 2012 at 9:53 AM, Daniel P. Berrange <berrange@xxxxxxxxxx>
>> > On Thu, Apr 26, 2012 at 09:05:41AM -0700, Matt Joyce wrote:
>> >> From a security stand point I am curious what you see the benefit as?
>> > Consider that you might have separate people in your data center
>> > managing the virtualization hosts, vs the storage hosts vs the
>> > network. As it standards today any of those groups of people can
>> > compromise data stored in a VM disk image (assuming a network based
>> > filesystem).
>> > First you encrypt the disk image, so that a person with access
>> > to the storage hosts, or network sniffing can't read any data. Then
>> > you have a central key server that only gives out the decryption key
>> > to Nova compute nodes when they have been explicitly authorized to
>> > run an instance of that VM.
>> > So now people with access to the storage hosts cannot compromise
>> > any data. People with access to the virtualization hosts can only
>> > compromise data if the host has been authorized to use that disk
>> > image
>> > You would need to compromise the precise host the VM disk is being
>> > used on, or compromise the key server or the management service
>> > that schedules VMs (thus authorizing key usage on a node).
>> > NB this is better than relying on the guest OS to do encryption,
>> > since you can do stricter decryption key management from the
>> > host side.
>> >> On Thu, Apr 26, 2012 at 8:53 AM, Michael Grosser
>> >> <dev@xxxxxxxxxxxxxxxxxx> wrote:
>> >> > Hey,
>> >> >
>> >> > I'm following the openstack development for some time now and I was
>> >> > wondering if there was a solution to spin up encrypted virtual
>> >> > machines by
>> >> > default and if it would be a huge performance blow.
>> >> >
>> >> > Any ideas?
>> > I would like to extend the libvirt driver in Nova to make use of the
>> > qcow2
>> > encryption capabilities between libvirt & QEMU which I describe here:
>> > http://berrange.com/posts/2009/12/02/using-qcow2-disk-encryption-with-libvirt-in-fedora-12/
>> > Regards,
>> > Daniel
>> > --
>> > |: http://berrange.com -o-
>> > http://www.flickr.com/photos/dberrange/ :|
>> > |: http://libvirt.org -o-
>> > http://virt-manager.org :|
>> > |: http://autobuild.org -o-
>> > http://search.cpan.org/~danberr/ :|
>> > |: http://entangle-photo.org -o-
>> > http://live.gnome.org/gtk-vnc :|
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp