Review for new rbac_playbook

[Till Maas]

On Sun, Jun 08, 2014 at 02:42:41AM +0100, Michael Scherer wrote:

> And after a quick crude test, if you have ssh listening on 2 ports, ssh
> will treat each as a different entry in known_hosts, and so ask again.
> ( or at least on my laptop, I didn't dig more given the hour, will try
> to search a bit more ).

Yes, I thought about it some more as well. This might indeed be a
problem. I see two kind of attacks. The one you describe is only
interesting for someone who is able to run ansible for a host but does
not have root access to the host. If it is possible to specify a
non-privileged port (e.g. 1234), the attacker can run its own SSH server
there to get access to all information sent by ansible but only for the
host the attacker has already access to. The required privileges are:

- Being able to login to a host
- Being able to run playbooks for a host
- Being able to specify the port for ansible to connect to

The attacker does not gain any advantage if they have already root
access to the host.

Getting information from a different host requires to modify the
playbook/ansible repo to send the wrong credentials from the private
repo to the system the attacker has access to. But then it could be
stored in a way that it is accessible for the attacker without root
access, so being able to change the port is not necessary.


Another possible attack is to run the playbook on a different host. For
this an attacker could forward the ssh port from target01 to
attacker01:1234 and run the playbook for attacker01 but port 1234. Then
it will be executed on target01, if ansible uses the right SSH private
key automatically and the same sudo password or no sudo password.

If the attacker has root access attacker01, they could also forward
attacker01:22 to target01:22, so being able to specify a port to ansible
is not required. But this requires the ssh hostkey not being checked.

Regards
Till