def can_run(acl, groups, playbook_file):
Le mercredi 04 juin 2014 à 19:45 -0600, Tim Flink a écrit :
So, I just have one question. how does the option -P of the script is> I've been working to rewrite and extend the script that we've been
> using to control playbook execution for folks who are not in
> I've been testing the script but before we actually start using it on
> lockbox01, I'd appreciate a review of the code to make sure I didn't
> miss any security holes.
> Injection attacks shouldn't be an issue due to usage of os.execv - all
> injection attempts are grouped as a single argument and will not be
> broken up.
supposed to behave ?
Can i assume that I would be able to say "use this playbook, but instead
of using the port 22, use port 1234" without changing the playbook ?
In this case, I think this would mean that if I can create a ssh tunnel
on the remote server ( listening to port 1234 to a server I control,
with ssh -L 1234:servericontrol:22 ), then I can make the playbook
played on a server I control, which in turn mean that I would
potentially get access to files with password that I may not have access
Example, the playbook that deploy mediawiki would deploy mediawiki on my
server, then i can go as root look at the mysql credentials deployed in
the configuration file. Or I can look at the https certificates that
were deployed, etc, etc.
I do not know if such attack schema would matter for Fedora infra, but
if the user running ansible ( after sudo, is sudoed a word ? ) has
access to passwords that the initial user don't, and if there is no
firewall internally ( ie, the tunnel trick would work, no firewall
between lockbock and the server ), and if the attack/initial user can
ssh to a server without much access, then, this would work.
( if not, I may just have won the Oscar for the most convoluted attack
of the week )
infrastructure mailing list