Open Stack

Sorry about the late replay.

It's dangerous if a cracker gets the private key.
The image data is encrypted during the transportation. But after that,
a cracker can copy any image include the resized/migrated one on the
dest compute node using the private key. And the dest node could be any
compute node. Under this situation encryption is not usefull.

By setting "write only = true" in rsyncd.conf, any attempted image
downloads will fail. This protects images on the dest compute node
from getting downloaded. AFAIK, sshd can't do this. One of its
shortage is that images on the dest node can be overwritten by rsync
command. Using ssh has this shortage, too.

If "use chroot" is set "yes" in rsyncd.conf, the rsync daemon will
chroot to the instances path before starting the file transfer with
the client. This is usefull.



2012/11/2 Eric Windisch <eric at cloudscaling.com>

>
> The disks are copied from source to destination via rysnc over ssh during
> resizing/migrating.
> It means that we will need a password-less ssh private key setup among all
> compute nodes.
> It is a security problem in some environment. This blueprint will use
> rsync itself(not over ssh)
> to copy/delete the disks.
>
> Are you planning to improve rsync? I don't think its more secure to use
> rsync without ssh, with rsync over ssh, not only we have the
> authentication, but also the data encryption during the transportation.
>  password-less ssh may have potential risk, but still its more secure than
> rsync itself.
>
> I suspect his concern is less about the protocol, but about how it is
> used.  The code forces all disk migrations to happen as 'root' and presumes
> that the systems have password-less ssh keys configured between them.
>
> While the rsync protocol would be less secure in and of itself, it is
> easily chrooted. It changes the attack surface. Instead of being able to
> compromise the dom0 from another (already) compromised dom0, you'll "only"
> able to compromise the guests from any host (as any user) that has access
> to rsync port.
>
> There are ways to make rsync+ssh more secure than it is used currently,
> but this may just be the wrong solution, period.
>
> Regards,
> Eric Windisch
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best,

Jian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121107/ae22ea9d/attachment.html>