Re: Groovy sandboxing
Paolo Di Tommaso <[email protected]> Mon, 3 Aug 2026 08:21:20 +0200
| Newsgroups | gmane.comp.lang.groovy.user |
|---|---|
| Message-ID | <CADgKzdxSaa37HRAdBFCQcHWrLgmd=N3O_qBRELuB6-dWvD+CsQ@mail.gmail.com> |
--000000000000162e1906581e8e96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jochen point made me think it could be possible (at least in principle) to run Groovy on Truffle, and therefore Graal + Sandboxing via Espresso (Java-on-Truffle) <https://www.graalvm.org/latest/reference-manual/espresso= > . Espresso is a full JVM implemented as a Truffle language, so it runs arbitrary JVM bytecode as guest code =E2=80=94 which means the Truffle sand= box policies apply to it. Since Groovy compiles to bytecode, you can compile the script on the host and then load and run that bytecode inside an Espresso Context, configured with HostAccess.NONE, IOAccess.NONE, no threads, etc. That gives you the file/socket/env restrictions you're after. Two caveats worth knowing: - The strong guarantees (isolated heap, CPU/memory limits, the ISOLATED/UNTRUSTED sandbox policies) require Oracle GraalVM and the truffle-enterprise artifact =E2=80=94 they're not in Community Edition, = which only gives you host-access control. - Espresso is still officially experimental (~2=E2=80=933=C3=97 slower t= han HotSpot), and Groovy leans heavily on invokedynamic, reflection, and runtime class generation, so expect some compatibility rough edges. Paolo On Mon, Aug 3, 2026 at 2:51=E2=80=AFAM Jochen Theodorou <[email protected]>= wrote: > Hi > > just to be clear... we are not talking about AI creating scripts to help > the AI analyze your code. We are talking about AI generated script for > specific tasks, that are then executed through some script engine? > > I think for the first case we could find a solution that works, for the > second it is more difficult actually. And that is where Pauls Email > comes into play. > > Did I think about making a Truffle Version of Groovy before? Sure. Never > saw how though. It would be similar to Graal executing Java code. > > Did I ever think of a GVM, yes, that too... but never in combination > with security. I mean such a GVM would be a modified JVM, because why > reinvent the wheel, even if the bytecode would be different, the JVM > base would probably be the same. And then the question is why we can > that way implement security, that is not wanted in that way for the JVM? > Which I think is kind of deciding of if it is worth to start such a > project even. And I currently have no answer to that. > > So Graal or GVM would maybe work for this. I personally never had the > time to properly explore the idea. And never thought about it with that > motivation as focus > > bye Jochen > > On 8/1/26 23:34, ski n wrote: > > 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 no= t > > 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/ <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. Historicall= y > > 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 > > --000000000000162e1906581e8e96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Jochen point made me think it could be possible (at least = in principle) to run Groovy on Truffle, and therefore Graal=C2=A0+ Sandboxi= ng via <a href=3D"https://www.graalvm.org/latest/reference-manual/espresso"= >Espresso (Java-on-Truffle)</a>.=C2=A0<div><br></div><div>Espresso is a ful= l JVM implemented as a Truffle language, so it runs arbitrary JVM bytecode = as guest code =E2=80=94 which means the Truffle sandbox policies apply to i= t. Since Groovy compiles to bytecode, you can compile the script on the hos= t and then load and run that bytecode inside an Espresso Context, configure= d with HostAccess.NONE, IOAccess.NONE, no threads, etc. That gives you the = file/socket/env restrictions you're after.<br><br>Two caveats worth kno= wing:<br><ul><li>The strong guarantees (isolated heap, CPU/memory limits, t= he ISOLATED/UNTRUSTED sandbox policies) require Oracle GraalVM and the truf= fle-enterprise artifact =E2=80=94 they're not in Community Edition, whi= ch only gives you host-access control.</li><li>Espresso is still officially= experimental (~2=E2=80=933=C3=97 slower than HotSpot), and Groovy leans he= avily on invokedynamic, reflection, and runtime class generation, so expect= some compatibility rough edges.</li></ul><div><br></div></div><div><br></d= iv><div>Paolo</div></div><br><div class=3D"gmail_quote gmail_quote_containe= r"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 3, 2026 at 2:51=E2=80= =AFAM Jochen Theodorou <<a href=3D"mailto:[email protected]">blackdrag@g= mx.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m= argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left= :1ex">Hi<br> <br> just to be clear... we are not talking about AI creating scripts to help <b= r> the AI analyze your code. We are talking about AI generated script for <br> specific tasks, that are then executed through some script engine?<br> <br> I think for the first case we could find a solution that works, for the <br= > second it is more difficult actually. And that is where Pauls Email <br> comes into play.<br> <br> Did I think about making a Truffle Version of Groovy before? Sure. Never <b= r> saw how though. It would be similar to Graal executing Java code.<br> <br> Did I ever think of a GVM, yes, that too... but never in combination <br> with security. I mean such a GVM would be a modified JVM, because why <br> reinvent the wheel, even if the bytecode would be different, the JVM <br> base would probably be the same. And then the question is why we can <br> that way implement security, that is not wanted in that way for the JVM? <b= r> Which I think is kind of deciding of if it is worth to start such a <br> project even. And I currently have no answer to that.<br> <br> So Graal or GVM would maybe work for this. I personally never had the <br> time to properly explore the idea. And never thought about it with that <br= > motivation as focus<br> <br> bye Jochen<br> <br> On 8/1/26 23:34, ski n wrote:<br> > Groovy has always been a powerful scripting language. Now with agents = <br> > (for example created with Spring AI or Langchain4j) it's becoming<= br> > more common to run Groovy scripts from for example Java or Kotlin.<br> > <br> > The question is when third-party generated scripts from agents (or jus= t <br> > a script written by other developers)<br> > run these scripts, how to run it safely and securely? For example by n= ot <br> > giving it access to the file system, socket or environment.<br> > <br> > I recently read the documentation of GraalVM on sandboxing:<br> > <br> > <a href=3D"https://www.graalvm.org/latest/security-guide/sandboxing/" = rel=3D"noreferrer" target=3D"_blank">https://www.graalvm.org/latest/securit= y-guide/sandboxing/</a> <https:// <br> > <a href=3D"http://www.graalvm.org/latest/security-guide/sandboxing/" r= el=3D"noreferrer" target=3D"_blank">www.graalvm.org/latest/security-guide/s= andboxing/</a>><br> > <br> > There you can have guest code (JavaScript, Python, Wasm etc) that is a= <br> > sandbox when started from the JVM/GraalVM. This works because guest <b= r> > languages<br> > run in a separate VM, truffle VM, where these restriction policies can= <br> > be applied.<br> > <br> > Groovy as being a JVM language itself, runs natively on the JVM, and i= s <br> > very much integrated with other JVM languages such as Java. Historical= ly <br> > there have been several approaches to run Groovy restrictly such as:<b= r> > <br> > SecureASTCustomizer<br> > custom classloaders<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 i= s <br> > no robust, built-in JVM mechanism for securely sandboxing arbitrary <b= r> > Groovy code.<br> > <br> > Are there any plans to allow strong sandboxing for Groovy embedded in = <br> > another JVM Language?<br> > <br> > Raymond<br> <br> </blockquote></div> --000000000000162e1906581e8e96--