Security policy in 2.0 breaks JConsole and VisualVM

Elastic Stack Elasticsearch
1

Hi,

I'm not sure if anyone's aware of this, but the new security manager/policy in ES 2.0 completely breaks JConsole and VisualVM. By "breaks" I mean that one cannot use them to connect to ES. This worked before the security manager/policy was introduced, of course.

Is this a known issue? Seems pretty critical to me.... should I open an issue on Github?

This is what happens now:

JConsole:

java.lang.SecurityException: Expecting a javax.rmi.ssl.SslRMIClientSocketFactory RMI client socket factory in stub!
at javax.management.remote.rmi.RMIConnector.checkStub(RMIConnector.java:1903)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:295)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
at sun.tools.jconsole.ProxyClient.tryConnect(ProxyClient.java:357)
at sun.tools.jconsole.ProxyClient.connect(ProxyClient.java:313)
at sun.tools.jconsole.VMPanel$2.run(VMPanel.java:294)
java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object
at java.security.Permissions.add(Permissions.java:126)
at java.security.Policy$UnsupportedEmptyCollection.add(Policy.java:827)
at sun.rmi.server.LoaderHandler.getLoaderAccessControlContext(LoaderHandler.java:1005)
at sun.rmi.server.LoaderHandler.lookupLoader(LoaderHandler.java:881)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:404)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:186)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:264)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:214)
...
...

JVisualVM:
jvisualvm: java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object
at java.security.Permissions.add(Permissions.java:126)
at java.security.Policy$UnsupportedEmptyCollection.add(Policy.java:827)
at sun.rmi.server.LoaderHandler.getLoaderAccessControlContext(LoaderHandler.java:1005)
at sun.rmi.server.LoaderHandler.lookupLoader(LoaderHandler.java:881)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:404)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:186)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:264)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:214)
...
...

Thanks,
Otis

Monitoring - Log Management - Alerting - Anomaly Detection
Elasticsearch Consulting - Support - Training - http://sematext.com/

2

IMO I'd open an issue for this.

If it's only for testing purpose, a workaround could be to disable security while running tests?

3

Right, but if you need to do this in prod, then what? :smile:
When things are not working well and you need to attach to use JConsole/VisualVM, then you can't stop ES, disable the security manager, and restart..

I'll open the issue, thanks David.

Otis

Monitoring - Log Management - Alerting - Anomaly Detection
Elasticsearch Consulting - Support - Training - http://sematext.com/

4

Opened https://github.com/elastic/elasticsearch/issues/14268 , but .... heh :disappointed:

Otis

Monitoring - Log Management - Alerting - Anomaly Detection
Elasticsearch Consulting - Support - Training - http://sematext.com/

5

Adding these lines to org.elasticsearch.bootstrap.ESPolicy will make a huge difference :slight_smile:

@Override
public PermissionCollection getPermissions(CodeSource codesource) {
    PermissionCollection pc = template.getPermissions(codesource);
    for (Enumeration<Permission> en = dynamic.elements(); en.hasMoreElements(); ) {
        pc.add(en.nextElement());
    }
    return pc;
}
6

Its never going to happen. And its total bullshit that code is trying to add to the result of getPermissions, its basically trying to backdoor its way through the system.

not a chance in hell i tell you.

7

Unfortunately, that's inside some ES jar, so it's not realistic to have people/ES users go in and modify ES jars...

Otis

Monitoring - Log Management - Alerting - Anomaly Detection
Elasticsearch Consulting - Support - Training - http://sematext.com/

8

Its also not realistic for us to maintain tons of hacks indefinitely because of others bugs. In this case the JDK bug has been open for a long time and nobody cares (https://bugs.openjdk.java.net/browse/JDK-8014008). I have a PR (https://github.com/elastic/elasticsearch/pull/14274) to workaround the bug, but I think some momentum needs to happen on that bug.

This is 100% a JDK bug and not a problem with elasticsearch.