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

[Zhigang Wang <zhigang.x.wang@oracle.com>]

On 09/17/2013 05: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:
> 
>  * An option to xl migrate which causes xl to make the TCP connection
>    itself.  This is a not-quite-trivial SMOP and the specification
>    ought to be trivial.
> 
>  * A separate executable (or perhaps argv[0] mode)
>    "xl-migrate-receive" so that the hosts.{allow,deny} etc. files
>    used by tcpd can contain "xl-migrate-receive" and not just "xl".
>    The specification for this would need to be discussed, but the
>    implementation will be trivial.
> 
>  * A command line option for logging redirection so that /all/ the
>    error messages from an inetd-launched xl migrate-receive go
>    somewhere useful.  The specification for this would need to be
>    discussed, but the implementation should be very simple.
> 
>  * Better documentation, particularly including a recipe for setting
>    this up, covering: inetd.conf, hosts.{allow,deny}, invocation at
>    the sending end, security considerations.

Thanks for the good explanation. We really want to use the upstream
solution. I will try the ssh solution first. Please go ahead and
implement the non-security solution. I can help for testing.

Zhigang