Open Stack

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.

-Matt

On Thu, Apr 26, 2012 at 3:08 PM, Justin Santa Barbara
<justin at fathomdb.com> wrote:
> 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?
>
> Justin
>
>
>
>
> On Thu, Apr 26, 2012 at 1:44 PM, Matt Joyce <matt at nycresistor.com> 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.
>>
>> -Matt
>>
>> On Thu, Apr 26, 2012 at 9:53 AM, Daniel P. Berrange <berrange at redhat.com>
>> wrote:
>> > 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 at seetheprogress.net> 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 at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>