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