Merge lp:~hazmat/pyjuju/security-specification into lp:pyjuju

[Kapil Thangavelu]

A basic overview of the security architecture, attack vectors, and next steps. its a bit rambling but hopefully it makes a good start.

[Gustavo Niemeyer (niemeyer)]

This is going into a very good direction.

Here are some comments on a first read:

[1]

47 +to each node. Every zookeeper connection can associate principal
48 +credentials to its connection, and all access by that connection is
49 +validated against the per node ACL mapping.

This would be a good place to link some upstream documentation for zk.

[2]

Just in terms of style, on the big reorganization I've standardized the headings
on the three styles:

  1) ===
  2) ---
  3) ~~~

I suggest we try to keep this convention across all documents, otherwise it's
hard to follow what's a sub-header or not (e.g. I wouldn't expect === as a
sub-header of ---)

[3]

55 +An additional zookeeper connected actor responsible for creating principals
56 +and providing an up to date token database.

Do we need to manage an external agent for that?

[4]

65 +Each actor employs a security policy, to determine the ACL map for a given
66 +node path that may create. The policy simply takes the path to the node
67 +to be created, and returns back an ACL map that can be set on the node.

This wasn't very clear on a first read. Some ideas:

- "employs" could mean different things in that context, so I suggest replacing by
  a less open synonym ("uses"?).

- "that may create" feels like missing the subject ("that the actor may
  create?")

- At least the first comma should be dropped.

- s/can be set/must be set/?

[5]

73 Every actor in the system needs its own
74 +unique principal, to provide an auth identity, the credentials for a
75 +principal are known only to the actor utilizing them and transiently
76 +the security agent when they are created.

This sentence isn't reading well.

[6]

78 +Instead of passing principals credentials directly via insecure
79 +channels, an actor creating another actor also establishes a principal
80 +creation token via the security agent. The principal creation token is
81 +a one time use string which can be used to create a principal and its
82 +password, and update the token database.
83 +
84 +The security agent has a simple policy in place regarding principal
85 +names and which actors can create them, ie. a provisioning agent can
86 +create machine principals, but not service unit principals.

It's not clear from the document how that's going to work, and it also feels a
little bit like delegating permissions could be more complexity than is
necessary (e.g. what about the agent itself creating these identities instead
of providing a one time token?). This area needs some debate.

[7]

88 +If a malicious user intercepts the token and uses it, compared with
89 +passing credentials directly it minimizes the time that a third party
90 +has to perform such an interception. Moreover invalid use of a token
91 +can be logged as foresenic information.

This assumes knowledge about about how such interceptions would take place,
or why it minimizes the time, that isn't available in the document up to
then.

Also, we should design the security system in a way that such interceptions
can't take place, rather than minimizing the time an interception can be
made (ssh vs. telnet).

[8]

118 +Additionally services utilize relations to communic...

review: Needs Fixing

[Clint Byrum (clint-fewbar)]

Hi Kapil.

I noticed you're suggesting MD5 for the password hashes. I'd suggest going 1 step further and using multiple iterations of MD5. Grid computing has made cracking a single MD5 password trivial. Hash 200,000 times, and at least you require 200,000 times more power to do a mass dictionary attack (and it shouldn't add much time considering how seldom the actual password will need to be checked.

[Gustavo Niemeyer (niemeyer)]

200k+MD5 is a bit too much, but I agree that using HMAC (perhaps HMAC+SHA1) rather than plain MD5 would be good. HMAC is targeted at specifically this use case too.

[Kapil Thangavelu (hazmat)]

Excerpts from Clint Byrum's message of Thu Jun 09 23:51:31 UTC 2011:
> Hi Kapil.
>
> I noticed you're suggesting MD5 for the password hashes. I'd suggest going 1 step further and using multiple iterations of MD5. Grid computing has made cracking a single MD5 password trivial. Hash 200,000 times, and at least you require 200,000 times more power to do a mass dictionary attack (and it shouldn't add much time considering how seldom the actual password will need to be checked.

Its actually not something we control explicitly as what we set for the acl identity token (the username:md5hash) needs to match the enforcement side which is provided by zookeeper. We could in future play around with a zk authentication plugin that we could provide custom logic for, but i think we've deemed modification of zk out of scope for the moment. I agree though that things like cuda/gpugpu programming and the fact that we're manipulating cloud environments, makes brute force attacks more likely and it would be nice to have a more resistant approach.

[Gustavo Niemeyer (niemeyer)]

Good point. On the bright side, these tokens are going to be automatically generated. We can easily make them long and random enough to invalidate any brute force attacks (not counting fancy quantum computing advancements ;-).

[lp:~hazmat/pyjuju/security-specification]

242. By Kapil Thangavelu on 2012-06-22

address some formatting comments

243. By Kapil Thangavelu on 2012-06-22

merge trunk and address some formatting comments

Unmerged revisions

243. By Kapil Thangavelu on 2012-06-22

merge trunk and address some formatting comments

242. By Kapil Thangavelu on 2012-06-22

address some formatting comments

241. By Kapil Thangavelu on 2011-06-08

additional escalation scenarios, outline next steps broadly

240. By Kapil Thangavelu on 2011-06-07

security overview and todo spec draft

=== added file 'docs/source/drafts/security.rst'
--- docs/source/drafts/security.rst	1970-01-01 00:00:00 +0000
+++ docs/source/drafts/security.rst	2012-06-22 15:29:20 +0000
@@ -0,0 +1,260 @@
+Security Overview
+=================
+
+Ensemble is committed to providing a reliable secure mechanism for
+deploying services. What follows is an overview of these different
+mechanisms and how they contribute to keeping an ensemble environment
+secure.
+
+Glossary
+--------
+
+First a glossary of terms used in this document.
+
+
+Principal
+~~~~~~~~~
+
+A principal in the context of ensemble can represent any actor or
+group of actors within the system. Each principal is authenticated via
+a user name/principal id and password. For example a service unit
+agent would associate its own unique principal information to its
+connection, and would thus have access to all nodes that have their
+ACL mapping explicitly giving access to the node.
+
+Token Database
+~~~~~~~~~~~~~~
+
+A mapping of principal id to their acl identity token. The identity
+token is a md5 checksum of username/password prefixed of the form
+username:identity_scheme:checksum, where identity_scheme is md5 in the
+case of ensemble. The mapping is stored in a zookeeper node which is
+world readable but only writable by the security (ticket granting)
+agent, which is responsible for creating principals.
+
+Zookeeper ACLs
+~~~~~~~~~~~~~~
+
+Ensemble relies on the security facilities provided by the zookeeper's
+coordination storage, whereby zookeeper automatically restricts access
+to each node, based on the ACL permission map on each node.  This ACL
+facility maps permissions to principal identity tokens.  Zookeeper
+provides permissions for read, write, delete, create, and admin access
+to each node. Every zookeeper connection can associate principal
+credentials to its connection, and all access by that connection is
+validated against the per node ACL mapping.
+
+
+Additional documentation available here.
+http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#sc_ZooKeeperAccessControl
+
+
+Security Agent
+~~~~~~~~~~~~~~
+
+An additional zookeeper connected actor responsible for creating principals
+and providing an up to date token database.
+
+The security agent manages a token database (definition to follow),
+and provides for the creation of new principals and handing out their
+hash tokens to inquiring parties.
+
+Security Policy
+~~~~~~~~~~~~~~~
+
+Each actor employs a security policy, to determine the ACL map for a given
+node path that may create. The policy simply takes the path to the node
+to be created, and returns back an ACL map that can be set on the node.
+
+
+Identity
+--------
+
+How the system passes credentials to an actor is a critical aspect to
+managing principals securely. Every actor in the system needs its own
+unique principal, to provide an auth identity, the credentials for a
+principal are known only to the actor utilizing them and transiently
+the security agent when they are created.
+
+Instead of passing principals credentials directly via insecure
+channels, an actor creating another actor also establishes a principal
+creation token via the security agent. The principal creation token is
+a one time use string which can be used to create a principal and its
+password, and update the token database.
+
+The security agent has a simple policy in place regarding principal
+names and which actors can create them, ie. a provisioning agent can
+create machine principals, but not service unit principals.
+
+If a malicious user intercepts the token and uses it, compared with
+passing credentials directly it minimizes the time that a third party
+has to perform such an interception. Moreover invalid use of a token
+can be logged as foresenic information.
+
+One question that emerges with the use of a separate agent for creating
+identities, is how agents needed for bootstrap recieve their credentials.
+
+ - The bootstrap can utilize a specialized OTP interface with a precreated
+   known value, which it can use to initialize the tree.
+
+Transport level security
+------------------------
+
+As zookeeper does not currently support SSL/TLS transport level
+security, Ensemble utilizes SSH port forwarding to ensure encrypted
+communications to zookeeper. One significant lacking to this approach,
+is that any process on the set of ensemble machines can attempt to
+connect zookeeper to brute force principal passwords.
+
+See Also Alternatives#NodeEncryption
+
+Privileged Data
+---------------
+
+Certain data stored within zookeeper, is by its nature privileged and
+should only be shared with agents requiring it for their function. For
+example the Ensemble provider credentials should only be exposed to
+the provisioning agent, as its required for it to function, any
+additional access to the data, would be regarded as a data escalation
+vulnerability.
+
+Additionally services utilize relations to communicate with each
+other, every service unit of the services participating within a
+relation gets write access only to its own node within the relation,
+and has read access to all service unit relation settings. An
+unrelated service unit from a different service, is not allowed to
+read any settings from the relation.
+
+
+Data Security
+-------------
+
+A pub key/priv key can be associated to the OTP to 
+
+
+OTP Security
+------------
+
+The otp is not secure without an additional enforcement, as it does
+not exist as a native capability of the zk interface. An additional
+actor responsible for creating identities and processing OTP tokens
+would be an alternative (See futures).
+
+
+Relations attacks
+-----------------
+
+Ensemble is comprised of a number of actors connecting to and
+communicating via a shared storage. When two services enter into a
+relation, a private bidirectional channel is created for them to
+exchange data.
+
+Ensemble ensures that the zookeeper nodes used for this communication
+are subject to the proper ACL constraints such that unrelated services
+are unable to access them.
+
+But these relations represent adhoc inter machine communication, which
+are formula defined. A malicious agent could possibly abuse one of
+these protocols to further compromise additional agents. Unlike other
+attack vectors in ensemble, this is one that ensemble can only make
+minimal safety guarantees regarding, outside of perhaps a simple
+validation of relation data (currently treated as a binary blob) with
+relation type associated schemas.
+
+The formulas executed by the unit agent provide for user executed code
+done within an lxc container (with root privileges). LXC provides
+limited support for security against root in a container, so a
+container compromise can escalate to a machine level compromise and
+those of the other units on a machine.
+
+
+Privilege Escalation Scenarios
+------------------------------
+
+We have serveral different levels of escalation within ensemble for
+malicious code that need to be considered.
+
+container escalation
+++++++++++++++++++++
+
+All formula hooks are executed within an lxc container to give a
+minimally isolated environment. This lxc container is rather trivially
+exploitable to gain root access on the machine, as formulas execute
+as root within the container and lxc provides minimal security guarantees
+atm, which leads to the next escalation level.
+
+Future work is needed to provide better security around lxc
+integration, perhaps via integration of apparmor and ongoing lxc
+isolation work.
+
+Machine escalation
+++++++++++++++++++
+
+A machine is considered compromised if malicious code has root access
+on the machine, all service units colocated on the machine are also
+considered compromised if this occurs.
+
+Agent Escalation
+++++++++++++++++
+
+An agent is considered compromised if malicious code has an open zookeeper
+connection with a valid actor principal identity. The malicious code
+has access to all data exposed via ACL to the compromised identity.
+
+Beyond these generic scenarios we have particular escalations which
+are effectively fatal, as they entail access to sensitive data that
+spans the ensemble environment or machine provider.
+
+A bootstrap machine compromise which allow for disk access could be
+considered fatal as the Ensemble shared state (zookeeper) data is
+resident on disk.
+
+Certain agents like the provisioning agent, compromise of whose identity
+would allow malicious code to utilize the machine provider credentials.
+
+
+Access to Deployed services
+----------------------------
+
+A plan for controlled public access to deployed services is provided
+separately by the expose-services specification.
+
+Currently all internal access within a machine provider environment
+like ec2 is unfiltered.
+
+In future we should have machine level firewalling to allow access
+between services based on their relations.
+
+Alternatives
+------------
+
+
+Node Encryption
+~~~~~~~~~~~~~~~
+
+Principal Agent
+~~~~~~~~~~~~~~~
+
+A security agent responsible for 
+ for transport security via node encryption.
+
+Next Steps
+----------
+
+SSH Host Identity Checks
+
+we should pull the ssh key of the machine into zk, so connections to a
+given machine can verify against valid keys of environment machines
+
+Formula Storage URLs
+
+Currently the formula storage access is referenced by a storage key
+which is retrieved via the machine provider storage interface. This
+requires access to the machine provider credentials by Formula Storage
+by machine agents, which they shouldn't need.
+
+- Security Agent & Token Database
+- Security Policy (Path Based ACL generator)
+- Connections w/ Principal
+
+