On Sat, 07 Jun 2014 17:48:16 +0100
Michael Scherer <misc(a)zarb.org> 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
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.