Le mercredi 04 juin 2014 à 19:45 -0600, Tim Flink a écrit : > 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 > sysadmin-main. > > https://bitbucket.org/tflink/rbac-ansible > > 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. So, I just have one question. how does the option -P of the script is 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 too. 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 ) -- Michael Scherer _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure