On Sat, 07 Jun 2014 17:48:16 +0100 Michael Scherer <misc@xxxxxxxx> wrote: > Le samedi 07 juin 2014 à 21:28 +0530, Anshu Prateek a écrit : > > 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. > > Then why do we use sudo and a filtering script if a attacker can > inject any playbook ? They cannot. It requires them to be in the checked out location on lockbox that uses could only update by having root on lockbox or commiting to git. > > My understanding was that people did have to commit first before being > able to run something ( in order to provide auditing ), and that the > sudo user do have access to stuff that the user/attacker don't ( like > ssh keys, for example ). My understanding was also that there is a > private repo is not readable by everybody, with various password, but > that the user running ansible ( ie, the one accessible by sudo ) can > read. Yep. sudo is used to see if the user is allowed to run rbac-playbook at all, then it checks further before running ansible-playbook. > And that sudo is used to make sure the initial user can only run > ansible, nothing ore. well, rbac-playbook then ansible-playbook, but yeah. > If these assumptions are false, yeah, the attacker is more complex > than needed. But as the idea is to permit to people who are not in > sysadmin-main to run playbooks, I think my assumptions are correct. Right. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
