[CRIU] [PATCH 2/2] p.haul: use ssh tunneling and controll it with ssh* cmdline opts
Pavel Emelyanov
xemul at parallels.com
Mon Oct 27 11:23:30 PDT 2014
On 10/27/2014 11:20 PM, Ruslan Kuprieiev wrote:
> On 27.10.2014 20:13, Pavel Emelyanov wrote:
>> On 10/27/2014 04:56 PM, Ruslan Kuprieiev wrote:
>>> Currently we have such security holes:
>>>
>>> 1) All p.haul traffic goes without any encryption, which is
>>> not safe at all, cosidering that attacker can easily peek memory pages
>>> of migrating process. Lets solve that by using ssh tunnel which allows
>>> us to easily encrypt and compress traffic.
>>> Compressing is useful only when connection is very slow, but will only
>>> slow down things on fast networks.
>>> Using ssh tunnel also allows us to solve keys\certificates management
>>> problem in a very common way that is familiar to any system administrator.
>>>
>>> 2) p.haul-service binds to 0.0.0.0 and is accesible from the outside
>>> for anyone who is trying to connect to it. So attacket can easily connect
>>> to p.haul-service and migrate some malicious process to the server.
>>> Lets fix that by binding p.haul-service to 127.0.0.1 so it is accessible
>>> only from its localhost.
>>>
>>> So, basically, we perform following actions when migrating process
>>> from src to dest:
>>> 1. (user at dest) Start p.haul-service on localhost:12345
>>> 2. (user at src) Create ssh tunnel:
>>> ssh -NC 54321:localhost:12345 remote_ip
>> This is done by p.haul, right? What if ssh will need to ask for
>> a password, what would it do?
>
> Good system administrators don't use passwords, they use keys =).
> http://www.linuxproblem.org/art_9.html
OK. Do you _enforce_ spawned ssh to use keys? And fail in case
keys are missing.
Thanks,
Pavel
More information about the CRIU
mailing list