From xen-devel-bounces@lists.xen.org Tue Sep 17 11:10:05 2013 Received: (at maildrop) by bugs.xenproject.org; 17 Sep 2013 10:10:05 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1VLsEP-0008VY-By for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 17 Sep 2013 11:10:05 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VLsBg-0003Ez-67; Tue, 17 Sep 2013 10:07:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VLsBf-0003Eq-7t for xen-devel@lists.xen.org; Tue, 17 Sep 2013 10:07:15 +0000 Received: from [85.158.139.211:50609] by server-14.bemta-5.messagelabs.com id DE/E3-12040-2D928325; Tue, 17 Sep 2013 10:07:14 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1379412432!2882315!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9985 invoked from network); 17 Sep 2013 10:07:13 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 17 Sep 2013 10:07:13 -0000 X-IronPort-AV: E=Sophos;i="4.90,922,1371081600"; d="scan'208";a="52170616" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 17 Sep 2013 10:07:11 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Tue, 17 Sep 2013 06:07:11 -0400 Received: from gateway-cbg.eng.citrite.net ([10.80.16.17] helo=[0.0.0.0]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1VLsBa-00055h-Pr; Tue, 17 Sep 2013 11:07:11 +0100 Message-ID: <523829CE.6020509@eu.citrix.com> Date: Tue, 17 Sep 2013 11:07:10 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Jackson 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> In-Reply-To: <21048.8272.465544.579024@mariner.uk.xensource.com> X-DLP: MIA1 Cc: Dario Faggioli , Zhigang Wang , publicity@lists.xenproject.org, xen-devel Subject: Re: [Xen-devel] Suggestion for merging xl save/restore/migrate/migrate-receive X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel