[POC] [Security Manager Replacement] GraalVM sandboxing

[reta]

Description

Use GraalVM capability to spin off a separate JVM to host the sandboxed component. With this model, it becomes possible to:

• run OpenSearch core on any JVM that GraalVM supports (without SM)
• use older JDK versions (up to 23) with SM enabled for non-trusted components

The POC does a bare minimum work to host the ShiroIdentityPlugin in the separated JVM (21.0.5+11-Ubuntu-1ubuntu124.10) that is running under SecurityManager:

OpenSearch home: /home/opensearch-3.0.0-SNAPSHOT
Host JVM version: 22.0.2+9-jvmci-b01
Polyglot JVM version: 21.0.5+11-Ubuntu-1ubuntu124.10
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by org.opensearch.bootstrap.Security (file:/home/opensearch-3.0.0-SNAPSHOT/lib/opensearch-3.0.0-SNAPSHOT.jar)
WARNING: Please consider reporting this to the maintainers of org.opensearch.bootstrap.Security
WARNING: System::setSecurityManager will be removed in a future release
Security Manager? org.opensearch.secure_sm.SecureSM@7b303608
[2024-12-16T15:00:18,828][WARN ][stderr                   ] [] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
[2024-12-16T15:00:18,864][WARN ][stderr                   ] [] SLF4J: Defaulting to no-operation (NOP) logger implementation
[2024-12-16T15:00:18,875][WARN ][stderr                   ] [] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Shiro Plugin? org.opensearch.identity.shiro.ShiroIdentityPlugin@5ddd3150
Exception in thread "main" access denied ("java.net.SocketPermission" "localhost:0" "listen,resolve")
	at <java> checkPermission(Ljava/security/Permission;)V(Unknown)
	at <java> checkPermission(Ljava/security/Permission;)V(java/security/AccessController.java:1071:0)
	at <java> checkPermission(Ljava/security/Permission;)V(java/lang/SecurityManager.java:411:0)
	at <java> checkListen(I)V(java/lang/SecurityManager.java:985:0)
	at <java> bind(Ljava/net/SocketAddress;I)V(java/net/ServerSocket.java:387:0)
	at <java> <init>(IILjava/net/InetAddress;)V(java/net/ServerSocket.java:278:0)
	at <java> <init>(I)V(java/net/ServerSocket.java:171:0)
	at <java> getSocket()Ljava/net/ServerSocket;(org/opensearch/identity/shiro/ShiroIdentityPlugin.java:144:0)
	at <java> RootNode for interop message: 'invokeMember'.(Unknown)
	at org.graalvm.polyglot.Value.invokeMember(Value.java:1021)
	at org.opensearch.espresso.sandbox.Sandbox.loadPlugin(Sandbox.java:86)
	at org.opensearch.espresso.sandbox.Sandbox.main(Sandbox.java:22)

Related Issues

Closes #16861

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

❌ Gradle check result for a8e52f3: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for 6201d8c: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[kumargu]

while i understand this is POC for the shiro plugin, the sandbox restrictions for a different plugin could differ and we'd need to build and load a different context?

[kumargu]

wonder if we set allowHostClassLoading(false), we'd still be able to load the plugin.

[reta]

I think these settings are only "applicable" to embedded context, and once external JVM is started, all restrictions are off (this is why we need SM here).

You can easily see the confirmation here, in theory allowIO(IOAccess.NONE) would cut any I/O off but it does not, the SM does (if we comment out SM initialization, the socket will be created):

	at <java> getSocket()Ljava/net/ServerSocket;(org/opensearch/identity/shiro/ShiroIdentityPlugin.java:144:0)

[reta]

while i understand this is POC for the shiro plugin, the sandbox restrictions for a different plugin could differ and we'd need to build and load a different context?

This is out of scope for sandbox but in scope of SM of the spawn JVM process. We apply the same security policy that OpenSearch core does now.

[kumargu]

Gotcha.

We apply the same security policy that OpenSearch core does now.

this also means we cannot apply/use the plugin level security policies?

[reta]

this also means we cannot apply/use the plugin level security policies?

Quite an opposite :-) the OpenSearch core does include all plugin security policies into consideration. So it is kind of bootstrapping OpenSearch core + plugin(s), the policies will be glued together (as it does now)

[kumargu]

You can easily see the confirmation here, in theory allowIO(IOAccess.NONE) would cut any I/O off but it does not, the SM does (if we comment out SM initialization, the socket will be created):

Thanks for pointing that.

[kumargu]

Thank-you again for putting this up.

Apart from the debugging pain, which i hope would be one-time while setting up a plugin); I don't see a reason why we would not include this as an alternative for SM. Let's see what others feel about it.

This would look much better, allowing plugins to move to JDK-24 with a real look-and-feel of a plugin sandbox env when Graal fully addresses oracle/graal#10239

[reta]

Apart from the debugging pain, which i hope would be one-time while setting up a plugin); I don't see a reason why we would not include this as an alternative for SM. Let's see what others feel about it.

I have included it here #16861 but to reiterate, the most difficult issue with such a model is communication between host and spawned JVM/context: it seems not being possible to wire up the services from the host JVM. I will spend more time to explore the limitations here.