Groovy sandboxing

--00000000000089bc7006580311e8
Content-Type: text/plain; charset="UTF-8"

Groovy has always been a powerful scripting language. Now with agents (for
example created with Spring AI or Langchain4j) it's becoming
more common to run Groovy scripts from for example Java or Kotlin.

The question is when third-party generated scripts from agents (or just a
script written by other developers)
run these scripts, how to run it safely and securely? For example by not
giving it access to the file system, socket or environment.

I recently read the documentation of GraalVM on sandboxing:

https://www.graalvm.org/latest/security-guide/sandboxing/

There you can have guest code (JavaScript, Python, Wasm etc) that is a
sandbox when started from the JVM/GraalVM. This works because guest
languages
run in a separate VM, truffle VM, where these restriction policies can be
applied.

Groovy as being a JVM language itself, runs natively on the JVM, and is
very much integrated with other JVM languages such as Java. Historically
there have been several approaches to run Groovy restrictly such as:

SecureASTCustomizer
custom classloaders
SecurityManager (now removed from Java)
bytecode rewriting
custom compilation restrictions

Unfortunately, after the removal of the Java Security Manager, there is no
robust, built-in JVM mechanism for securely sandboxing arbitrary Groovy
code.

Are there any plans to allow strong sandboxing for Groovy embedded in
another JVM Language?

Raymond

--00000000000089bc7006580311e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Groovy has always been a powerful scripting language.=
 Now with agents (for example created with Spring AI or Langchain4j) it&#39=
;s becoming<br>more common to run Groovy scripts from for example Java or K=
otlin.=C2=A0<br><br>The question is when third-party generated scripts from=
 agents (or just a script written by other developers)<br>run these scripts=
, how to run it safely and securely? For example by not giving it access to=
 the file system, socket or environment.<br><br>I recently read the documen=
tation of GraalVM on sandboxing:<br><br><a href=3D"https://www.graalvm.org/=
latest/security-guide/sandboxing/">https://www.graalvm.org/latest/security-=
guide/sandboxing/</a><br><br>There you can have guest code (JavaScript, Pyt=
hon, Wasm etc) that is a sandbox when started from the JVM/GraalVM. This wo=
rks because guest languages<br>run in a separate VM, truffle VM, where thes=
e restriction policies can be applied.<br><br>Groovy as being a JVM languag=
e itself, runs natively on the JVM, and is very much integrated with other =
JVM languages such as Java. Historically there have been several approaches=
 to run Groovy restrictly such as:<br><br>SecureASTCustomizer<br>custom cla=
ssloaders<br>SecurityManager (now removed from Java)<br>bytecode rewriting<=
br>custom compilation restrictions<br><br>Unfortunately, after the removal =
of the Java Security Manager, there is no robust, built-in JVM mechanism fo=
r securely sandboxing arbitrary Groovy code.<br><br>Are there any plans to =
allow strong sandboxing for Groovy embedded in another JVM Language?<br><br=
></div>Raymond</div>

--00000000000089bc7006580311e8--