From xen-devel-bounces@lists.xen.org Tue Sep 17 10:30:04 2013
Received: (at maildrop) by bugs.xenproject.org; 17 Sep 2013 09:30:04 +0000
Received: from lists.xen.org ([50.57.142.19])
by bugs.xenproject.org with esmtp (Exim 4.80)
(envelope-from )
id 1VLrbg-00086I-T7
for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 17 Sep 2013 10:30:04 +0100
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
by lists.xen.org with esmtp (Exim 4.72)
(envelope-from )
id 1VLrYv-0002cu-2z; Tue, 17 Sep 2013 09:27:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
by lists.xen.org with esmtp (Exim 4.72)
(envelope-from ) id 1VLrYt-0002cp-SQ
for xen-devel@lists.xen.org; Tue, 17 Sep 2013 09:27:12 +0000
Received: from [85.158.139.211:18353] by server-14.bemta-5.messagelabs.com id
C2/39-12040-F6028325; Tue, 17 Sep 2013 09:27:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1379410028!2864101!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor:
VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n
X-StarScan-Received:
X-StarScan-Version: 6.9.12; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24778 invoked from network); 17 Sep 2013 09:27:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
17 Sep 2013 09:27:10 -0000
X-IronPort-AV: E=Sophos;i="4.90,922,1371081600"; d="scan'208";a="54587190"
Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net)
([10.9.154.239])
by FTLPIPO01.CITRIX.COM with ESMTP; 17 Sep 2013 09:26:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id
14.2.342.4; Tue, 17 Sep 2013 05:26:41 -0400
Received: from mariner.cam.xci-test.com ([10.80.2.22]
helo=mariner.uk.xensource.com ident=Debian-exim) by
norwich.cam.xci-test.com
with esmtp (Exim 4.72) (envelope-from ) id
1VLrYO-0001fC-Te; Tue, 17 Sep 2013 09:26:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80)
(envelope-from ) id 1VLrYO-0003VE-KR;
Tue, 17 Sep 2013 10:26:40 +0100
From: Ian Jackson
MIME-Version: 1.0
Message-ID: <21048.8272.465544.579024@mariner.uk.xensource.com>
Date: Tue, 17 Sep 2013 10:26:40 +0100
To: George Dunlap
In-Reply-To: <523811E8.6080304@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>
X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu)
X-DLP: MIA1
Cc: Zhigang Wang ,
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel