[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Suggestion for merging xl save/restore/migrate/migrate-receive
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@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |