[
https://issues.apache.org/jira/browse/ZOOKEEPER-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15384994#comment-15384994
]
Michael Han edited comment on ZOOKEEPER-2014 at 8/23/16 4:05 AM:
-----------------------------------------------------------------
Had an offline discussion with [~phunt], [~fpj] yesterday regarding this issue,
the conversation is captured as following points (with some of my thoughts as
well):
* We can't fix security issue unless we enforce authentication and
authorization. Just by moving client APIs around is not enough because at
protocol level the server still open to reconfiguration and someone can exploit
this easily (by writing their own ZK client instead of using ZooKeeper client
for example.).
* That said though, the ZooKeeper::reconfig API should be moved out of
ZooKeeper class (for Java client) anyway, because it's more about an admin
feature rather than a client API. Moving reconfig out of ZooKeeper will also
remove constraints we possibly put on normal ZooKeeper clients (such as having
to use zookeeper.DigestAuthenticationProvider.superDigest), which is a bonus.
Due to API backward compatibility concerns, this refactoring should happen
before we move to beta.
* We'd like to introduce a new configuration option in zoo.cfg to turn off
reconfig feature by default. ZK users who needs use this feature need turn it
on explicitly. Because dynamic reconfig feature brings something new (e.g.
cfg.dynamic file), have this feature off is good for 'the principal of least
surprise'. Having the feature off by default will also buy us sometime to
fortify and stabilize the feature without having it being a blocker issue.
The action items / plans I am thinking in the time frame of 3.5.3:
* Fix Security:
#* Enforce an ACL on /zookeeper/config, such that only users that have write
permission to it can reconfig the cluster. /zookeeper/config is by default
readable to anyone so zookeeper (none-admin) clients can load balancing on
client side either manually (current behavior) or automatically
(ZOOKEEPER-2016).
#* ZooKeeper users are responsible for properly configure the ACL such that
only a limited set of admin users are part of the ACL with write access. The
authentication of these users will be delegated to existing mechanisms
ZooKeeper already supports, such as SASL client login, so not much work here
except documentation on such a requirement to use reconfig feature.
#* The default behavior is such that if /zookeeper/config node has no
associated ACLs, then no one is allowed write access except super user.
* Fix API:
#* Create a new class ZooKeeperAdmin that inherits ZooKeeper class.
#* Move reconfig API into ZooKeeperAdmin class.
* Introduce a new zoo.cfg option to switch reconfiguration feature on or off.
The new configuration option will be set as 'disable reconfig' by default when
3.5.3 shipped, and user who wants reconfig has to enable reconfig option
explicitly.
Are these good enough for now to address all security concerns or we still miss
something?
Comments?
CC [~shralex], [~rgs]
was (Author: hanm):
Had an offline discussion with [~phunt], [~fpj] yesterday regarding this issue,
the conversation is captured as following points (with some of my thoughts as
well):
* We can't fix security issue unless we enforce authentication and
authorization. Just by moving client APIs around is not enough because at
protocol level the server still open to reconfiguration and someone can exploit
this easily (by writing their own ZK client instead of using ZooKeeper client
for example.).
* That said though, the ZooKeeper::reconfig API should be moved out of
ZooKeeper class (for Java client) anyway, because it's more about an admin
feature rather than a client API. Moving reconfig out of ZooKeeper will also
remove constraints we possibly put on normal ZooKeeper clients (such as having
to use zookeeper.DigestAuthenticationProvider.superDigest), which is a bonus.
Due to API backward compatibility concerns, this refactoring should happen
before we move to beta.
* We'd like to introduce a new configuration option in zoo.cfg to turn off
reconfig feature by default. ZK users who needs use this feature need turn it
on explicitly. Because dynamic reconfig feature brings something new (e.g.
cfg.dynamic file), have this feature off is good for 'the principal of least
surprise'. Having the feature off by default will also buy us sometime to
fortify and stabilize the feature without having it being a blocker issue.
The action items / plans I am thinking in the time frame of 3.5.3:
* Fix Security:
#* Enforce an ACL on /zookeeper/config, such that only users that have write
permission to it can reconfig the cluster. /zookeeper/config is by default
readable to anyone so zookeeper (none-admin) clients can load balancing on
client side either manually (current behavior) or automatically
(ZOOKEEPER-2016).
#* ZooKeeper users are responsible for properly configure the ACL such that
only a limited set of admin users are part of the ACL with write access. The
authentication of these users will be delegated to existing mechanisms
ZooKeeper already supports, such as SASL client login, so not much work here
except documentation on such a requirement to use reconfig feature.
#* The default behavior is such that if /zookeeper/config node has no
associated ACLs, then no one is allowed write access except super user.
* Fix API:
#* Create a new class ZooKeeperAdmin that inherits ZooKeeper class.
#* Move reconfig and getConfig API into ZooKeeperAdmin class.
* Introduce a new zoo.cfg option to switch reconfiguration feature on or off.
The new configuration option will be set as 'disable reconfig' by default when
3.5.3 shipped, and user who wants reconfig has to enable reconfig option
explicitly.
Are these good enough for now to address all security concerns or we still miss
something?
Comments?
CC [~shralex], [~rgs]
> Only admin should be allowed to reconfig a cluster
> --------------------------------------------------
>
> Key: ZOOKEEPER-2014
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2014
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.5.0
> Reporter: Raul Gutierrez Segales
> Assignee: Michael Han
> Priority: Blocker
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2014.patch
>
>
> ZOOKEEPER-107 introduces reconfiguration support via the reconfig() call. We
> should, at the very least, ensure that only the Admin can reconfigure a
> cluster. Perhaps restricting access to /zookeeper/config as well, though this
> is debatable. Surely one could ensure Admin only access via an ACL, but that
> would leave everyone who doesn't use ACLs unprotected. We could also force a
> default ACL to make it a bit more consistent (maybe).
> Finally, making reconfig() only available to Admins means they have to run
> with zookeeper.DigestAuthenticationProvider.superDigest (which I am not sure
> if everyone does, or how would it work with other authentication providers).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
