Juju newbie questions

[Clint Byrum]

Excerpts from Thomas Leonard's message of 2012-06-25 02:06:47 -0700:
> Hi Kapil,
> 
> That's useful to know. Is there a document somewhere describing the security 
> model (e.g. what kinds of deployments should be safe)? A diagram showing the 
> various components (juju client, ZooKeeper, etc) and how they communicate 
> would be useful.
> 
> As I understand it so far:
> 
> - ZooKeeper must not run on a machine with any untrusted users/software
> - Attackers must not have access to ZooKeeper's port
> - Deployed VMs must have access to ZooKeeper
> 
> Does this means that all VMs in one Juju environment are considered to be 
> equally trusted?
> 
> For example, if I deploy a web service and a logging service, can I rely on 
> the security features of the logging service to prevent an attacker who 
> compromises the web service from deleting the logs? Or, would getting 
> control of the web service VM automatically allow the attacker to compromise 
> the logger VM too?

First, best you have a read of all these bugs:

https://bugs.launchpad.net/juju/+bugs?field.tag=security

Juju's *intended* security model should be sound, as it will have ACL's for
all of the paths in ZooKeeper and individual authentication credentials for
all of the agents.

https://bugs.launchpad.net/juju/+bug/813773

This seems to be blocked right now on a bug in libzookeeper.

So, right now, any agent can do bad things if they can connect to
zookeeper.  This includes reading /writing the AWS credentials in EC2,
and all of the relation data.

To root any box once you can execute, say, python on the box, would  be
trivial, as one can simply:

* Execute python script which reads AWS creds from ZK
* setup environments.yaml, now you can just run as a juju admin
* Destroy a running service on machine X
* Deploy trojaned charm as service, it will end up on machine X

I'd recommend mitigating these problems (which have been public for a long long
time) by adding this rule to all deployed machines:

iptables -A OUTPUT -p tcp --dport 2181 -m owner \! --uid-owner 0 -j REJECT

This will at least require that they *root* one box before they can root
all the others.