From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Suggestion for merging xl save/restore/migrate/migrate-receive Date: Tue, 17 Sep 2013 11:07:10 +0100 Message-ID: <523829CE.6020509@eu.citrix.com> References: <523337AA.5080103@oracle.com> <5237291C.9090100@oracle.com> <21047.12251.625579.745154@mariner.uk.xensource.com> <523742B3.5040204@oracle.com> <523811E8.6080304@eu.citrix.com> <21048.8272.465544.579024@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21048.8272.465544.579024@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Dario Faggioli , Zhigang Wang , publicity@lists.xenproject.org, xen-devel List-Id: xen-devel@lists.xenproject.org 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