Re: Suggestion for merging xl save/restore/migrate/migrate-receive

[George Dunlap <george.dunlap@eu.citrix.com>]

On 09/17/2013 10:26 AM, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] Suggestion for merging xl save/restore/migrate/migrate-receive"):
>> On 09/16/2013 06:41 PM, Zhigang Wang wrote:
>>> ... Also after this, all Servers in a pool can login to each
>>> other. I don't know whether it's a security issue for our product.
>>>
>>> This is something we try to avoid at this time.
>>
>> ...so instead of allowing anyone on one of the hosts log in, you're
>> going to allow anyone with access to the network to create a VM without
>> any kind of authentication?
>>
>>   From a security perspective, that doesn't really sound like an
>> improvement...
>
> Note that if host B allows incoming migrations from host A, then host
> B is trusting host A completely.  This is because the migration data
> contains not just the guest's state (which is of course encapsulated
> inside the Xen VM security boundary), but also the VM configuration.
> The VM configuration specifies the mapping between guest resources and
> host resources.
>
> So host B trusts host A to specify the correct set of host B's own
> resources to expose to the guest VM.  If host A is malicious it can
> send a VM whose configuration specifies (for example) that the whole
> of host B's disk is to be exposed to the guest, along with a guest
> which will make whatever malicious changes host A desires.
>
> In summary: accepting incoming migration images is just as dangerous
> as allowing root login (from the same source host).  So switching the
> transport from ssh to unauthenticated ssl makes the security against
> malicious migration source hosts strictly worse.
>
> The only way unauthenticated ssl is better than simply unauthenticated
> unencrypted TCP is protection against passive eavesdropping.  This is
> important for much general traffic on the public Internet (see recent
> revelations about widespread eavesdropping), but probably not relevant
> for the control plane of a VM hosting setup.  If your control plane
> network has bad people on it, you need authentication as well as
> encryption.
>
>
> So I don't think we should be adding new code to xl which might
> encourage the use of ssl.  The proposed format-string based template
> would be OK, but I think really that we should have better (more
> convenient) support for unencrypted migration.
>
> Things that would be helpful:

And once we get all this sorted out, a blog post and/or wiki page with 
the issues, the options as they exist in the most recent release, and 
the options as they will exist in the next release, would be helpful.

  -George