[CRIU] [PATCH 2/2] p.haul: use ssh tunneling and controll it with ssh* cmdline opts
Ruslan Kuprieiev
kupruser at gmail.com
Mon Oct 27 12:33:40 PDT 2014
On 27.10.2014 20:23, Pavel Emelyanov wrote:
> 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?
>> http://www.linuxproblem.org/art_9.html
>> 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.
It is common practice to not use passwords in scripts.
We call ssh using Popen, so there is actually no good way to
use ssh with password. Yes, it will fail if keys are not authorized.
> Thanks,
> Pavel
>
>
More information about the CRIU
mailing list