Re: Review for new rbac_playbook

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



mmm, for your attack strategy to work, basically the "attacker" need to have enough permissions in the first place to be able to execute the playbook such that the playbooks have access to the mysql secret? And if he already has that kinda permission, then there is no need to do a setup first and then read it coz the attacker can read it upfront without doing the setup.

I think this is controlled by the..
def can_run(acl, groups, playbook_file): 

?


On Sat, Jun 7, 2014 at 8:56 PM, Michael Scherer <misc@xxxxxxxx> wrote:
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

_______________________________________________
infrastructure mailing list
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux