Page History

...

Status: Draft | Discussion | Development | Active | Dropped | Superseded

Superseded by: N/A

...

All out of the box authorizers will be implemented to prevent security problems but, due to the fact that we can't automatically detect in place modifications nor automatically define the trust boundary, the configurable ones will require extra care regarding the configuration or domain model design on the user side. The following table presents a brief summary of what "threats" (of the ones shown within the Introduction) are fully addressed by each implementation, and which ones might be exploitable depending on how the administrator configures the authorizer (the details will be described in each individual section when applicable, and clear documentation around this should be added to the user guide if we choose to implement these authorizers).

Authorizer \ Threat	Reflection	Cache Access	Region Access	Entry Modification
RestrictedMethodAuthorizer
UnrestrictedMethodAuthorizer
RegExMethodAuthorizer
JavaBeanAccessorMethodAuthorizer

Implementation Details

This section is just an overview and it contains some ideas of how the proposal could be achieved, no PoC has been done so far so the implementations details might change.

...

1. The contract for the interface MethodInvocationAuthorizer won't include a throws clause for the NotAuthorizedException class, that exception was designed to indicate that the subject is not allowed to execute a particular operation, not to indicate that a problem has occurred and that the authorization can not be determined. Since Geode can't do anything to recover from such errors and doesn't have any insights about the actual implementation, a non checked exception should be thrown whenever there's an error while executing the authorization logic.
2. Authorizer Implementations won't have Based as part of the actual name since the word doesn't add anything useful to the class name.
3. Class name for GeodeBasedMethodAuthorizer was changed to MethodUnrestrictedMethodAuthorizer.
4. Method name isKnownDangerousMethod was changed to isPermanentlyForbiddenMethod.
5. The IndexManager was modified to throw an exception and mark the index as invalid whenever the removal of an entry from an index fails. This was the behaviour used when adding mappings to an index, so the class was fixed to keep consistency between the different operations and to be able to mark existing indexes as invalid whenever a newly configured MethodInvocationAuthorizer doesn't allow the method invocations included within the index expression (see GEODE-7486 and GEODE-7351).
6. The CQ Engine was modified to always use the most up to date configured MethodInvocationAuthorizer. Whenever the MethodInvocationAuthorizer is changed in runtime, all running CQs are updated to use it in order to avoid security issues and previously cached results are invalidated/cleared as cached keys may not be valid anymore (see GEODE-7487, GEODE-7497 and GEODE-7351).