Hi,
I consider the ansible host as trusted, the target server that is
managed with ansible is considered less trusted (it might start attacks
against the ansible host).
Does ansible's security design match that threat model in general?
Given the following fetch module example:
- fetch: src={{ DataDir }}/{{ item[0] }}/{{ item[1] }}
dest={{ foo_dir }}/{{ item[0] }}/{{ item[1] }}.untrustedremotefile
flat=yes
with_nested:
- "{{ ansible_all_ipv4_addresses }}"
- [ 'a', 'b' ]
become: yes
I assume the target host trying to attack the ansible hosts can provide
arbitrary strings (i.e "../../../../")
as one of its IP addresses to trick the ansible host to write to
arbitrary locations (flat=yes) , but is it at least safe to assume that
the static strings defined in the playbook/role ('a', 'b' and file
suffix '.untrustedremotefile') can not be altered by the target server
or is the entire dest= path composed/generated remotely and transmitted
back to the ansible host and therefore considered untrusted entirely?
If static strings can not be altered by the remote (attacking) server
the remote server would only be able to override files named
a/b.untrustedremotefile in arbitrary locations but not for example
~/.ssh/authorized_keys.
Another question that came up while writing this email:
Is 'become: yes' in the fetch context limited to the target server or
will ansible try to escalate its privileges on the ansible host as well
(localhost)?
thanks!
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/5660D2F0.1070301%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
