Re: Groovy sandboxing
ski n <[email protected]> Mon, 3 Aug 2026 21:40:04 +0200
| Newsgroups | gmane.comp.lang.groovy.user |
|---|---|
| Message-ID | <CABKVO1Vab_ioxZ5foD7bOG7mBQ5+qyu_dbF8WNFgscdewjM=ug@mail.gmail.com> |
--00000000000034de3e065829b5ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for all the responses and feedback. Sandboxing does indeed seem like a major project, but there=E2=80=99s also a lot to gain. To clarify our use case: We are developing a platform based on Apache Camel. It's basically a UI where people can build integrations themselves. Camel provides many components and patterns as standard, but there will always be cases that aren't covered. To address this, we traditionally provide support for JavaScript and Groovy (originally Java 8), using the SecurityManager for sandboxing. At a certain point, the JavaScript engine Rhino was deprecated/removed from Java, and we advised all our users to use Groovy instead. The original intention was that users would develop a few Groovy scripts, but many people found it useful, especially developers who would rather write code than routes. So instead of the expected few dozen Groovy scripts, there are now thousands (around 30,000 different scripts). When we moved to JDK21, we encountered the issue that the Java Security Manager had been deprecated and would be fully removed in JDK24. Meanwhile, Camel started supporting JavaScript again through GraalJS, so we may offer it again. However, almost all users now use Groovy, are happy with it, and want to stick with it. This is even more the case because, with the advent of AI, more and more scripts are being generated by users and agents. With all this, sandboxing has become increasingly important. We checked and saw that the Jenkins team had previously encountered similar issues and created a library for them. However, as their GitHub page says, that library is deprecated, so we are currently using the following fork: https://github.com/craftercms/groovy-sandbox This library however isn't really a sandbox, but works more with intecepton, than really with isolation. Though you can use blacklisting/whitelisting approaches, but those are not long term solutions= . I think better solutions have already been proposed here. To add to this information, Gilles Duboscq, researcher at Oracle writese: "For JVM languages there is Espresso <https://www.graalvm.org/latest/reference-manual/espresso/> which is a Truffle implementation of the JVM. Sandboxing it presents some challenges though, especially around native code: by default espresso uses the standard java and native code of OpenJDK for its standard library. To truly sandbox espresso, this native should either itself be sandboxed or not used as all and Truffle APIs used instead. We did some experiments in that direction already though, with a "no-native" mode that can already run some simple workloads. Combining this with Polyglot Isolates could be a path forward for using this sandboxing with JVM languages." All of our Groovy are dynamically run, so we use JIT, but native is also something to consider. Raymond On Mon, Aug 3, 2026 at 8:22=E2=80=AFAM Paolo Di Tommaso <paolo.ditommaso@gm= ail.com> wrote: > Jochen point made me think it could be possible (at least in principle) t= o > 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 sa= ndbox > 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 afte= r. > > 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= than > 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]= g> 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 jus= t >> > 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/ <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 i= s >> > 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 i= s >> > 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 >> >> --00000000000034de3e065829b5ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div><di= v><div><div><div>Thank you for all the responses and feedback. Sandboxing d= oes indeed seem like a major project, but there=E2=80=99s also a lot to gai= n.<br></div></div></div></div></div></div></div></div></div></div></div></d= iv> <p>To clarify our use case: We are developing a platform based on Apache Ca= mel. It's basically a UI where people can build integrations themselves= . Camel provides many components and patterns as standard, but there will a= lways be cases that aren't covered. To address this, we traditionally p= rovide support for JavaScript and Groovy (originally Java 8), using the Sec= urityManager for sandboxing.</p><p>At a certain point, the JavaScript engin= e Rhino was deprecated/removed from Java, and we advised all our users to u= se Groovy instead. The original intention was that users would develop a fe= w Groovy scripts, but many people found it useful, especially developers wh= o would rather write code than routes. So instead of the expected few dozen= Groovy scripts, there are now thousands (around 30,000 different scripts).= When we moved to JDK21, we encountered the issue that the Java Security Ma= nager had been deprecated and would be fully removed in JDK24.</p><p></p><p= >Meanwhile, Camel started supporting JavaScript again through GraalJS, so w= e may offer it again. However, almost all users now use Groovy, are happy w= ith it, and want to stick with it. This is even more the case because, with= the advent of AI, more and more scripts are being generated by users and a= gents. With all this, sandboxing has become increasingly important.</p><p><= /p><p>We checked and saw that the Jenkins team had previously encountered s= imilar issues and created a library for them. However, as their GitHub page= says, that library is deprecated, so we are currently using the following = fork:</p><a href=3D"https://github.com/craftercms/groovy-sandbox">https://g= ithub.com/craftercms/groovy-sandbox</a><br><br></div>This library however i= sn't really a sandbox, but works more with intecepton, than really with= isolation. Though you can use blacklisting/whitelisting approaches, but th= ose=C2=A0are not long term solutions.<br>I think better solutions have alre= ady been proposed here.<br><br></div>To add to this information,=C2=A0=C2= =A0Gilles Duboscq, researcher at Oracle writese:<br> <p id=3D"gmail-d3d9" class=3D"gmail-pw-post-body-paragraph gmail-ft gmail-f= u gmail-fv gmail-fw gmail-b gmail-fx gmail-fy gmail-fz gmail-ga gmail-gb gm= ail-gc gmail-gd gmail-ge gmail-gf gmail-gg gmail-gh gmail-gi gmail-gj gmail= -gk gmail-gl gmail-gm gmail-gn gmail-go gmail-gp gmail-gq gmail-gr gmail-fo= gmail-cc">"For JVM languages there is <a class=3D"gmail-as gmail-gs" = href=3D"https://www.graalvm.org/latest/reference-manual/espresso/" rel=3D"n= oopener ugc nofollow" target=3D"_blank">Espresso</a> which is a Truffle imp= lementation of the JVM.</p><p id=3D"gmail-8c3b" class=3D"gmail-pw-post-body= -paragraph gmail-ft gmail-fu gmail-fv gmail-fw gmail-b gmail-fx gmail-fy gm= ail-fz gmail-ga gmail-gb gmail-gc gmail-gd gmail-ge gmail-gf gmail-gg gmail= -gh gmail-gi gmail-gj gmail-gk gmail-gl gmail-gm gmail-gn gmail-go gmail-gp= gmail-gq gmail-gr gmail-fo gmail-cc">Sandboxing it presents some challenges though, especially around native code: by=20 default espresso uses the standard java and native code of OpenJDK for=20 its standard library.</p><div class=3D"gmail-gt gmail-am"><div class=3D"gma= il-e">To truly sandbox espresso, this native should either itself be sandbo= xed or not used as all and Truffle APIs used instead.</div></div><p id=3D"g= mail-2ebb" class=3D"gmail-pw-post-body-paragraph gmail-ft gmail-fu gmail-fv= gmail-fw gmail-b gmail-fx gmail-fy gmail-fz gmail-ga gmail-gb gmail-gc gma= il-gd gmail-ge gmail-gf gmail-gg gmail-gh gmail-gi gmail-gj gmail-gk gmail-= gl gmail-gm gmail-gn gmail-go gmail-gp gmail-gq gmail-gr gmail-fo gmail-cc"= >We did some experiments in that direction already though, with a "no-= native" mode that can already run some simple workloads.</p><p id=3D"g= mail-f4dc" class=3D"gmail-pw-post-body-paragraph gmail-ft gmail-fu gmail-fv= gmail-fw gmail-b gmail-fx gmail-fy gmail-fz gmail-ga gmail-gb gmail-gc gma= il-gd gmail-ge gmail-gf gmail-gg gmail-gh gmail-gi gmail-gj gmail-gk gmail-= gl gmail-gm gmail-gn gmail-go gmail-gp gmail-gq gmail-gr gmail-fo gmail-cc"= >Combining this with Polyglot Isolates could be a path forward for using th= is sandboxing with JVM languages."</p>All of our Groovy are dynamicall= y run, so we use JIT, but native is also something to consider.<br><br></di= v>Raymond<div><br><br><div><br><br><div><br><br><br></div></div></div></div= ><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" clas= s=3D"gmail_attr">On Mon, Aug 3, 2026 at 8:22=E2=80=AFAM Paolo Di Tommaso &l= t;<a href=3D"mailto:[email protected]">[email protected]</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di= v 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+ Sandboxing = via <a href=3D"https://www.graalvm.org/latest/reference-manual/espresso" ta= rget=3D"_blank">Espresso (Java-on-Truffle)</a>.=C2=A0<div><br></div><div>Es= presso is a full JVM implemented as a Truffle language, so it runs arbitrar= y JVM bytecode as guest code =E2=80=94 which means the Truffle sandbox poli= cies apply to it. Since Groovy compiles to bytecode, you can compile the sc= ript on the host and then load and run that bytecode inside an Espresso Con= text, configured with HostAccess.NONE, IOAccess.NONE, no threads, etc. That= gives you the file/socket/env restrictions you're after.<br><br>Two ca= veats worth knowing:<br><ul><li>The strong guarantees (isolated heap, CPU/m= emory limits, the ISOLATED/UNTRUSTED sandbox policies) require Oracle Graal= VM and the truffle-enterprise artifact =E2=80=94 they're not in Communi= ty Edition, which only gives you host-access control.</li><li>Espresso is s= till officially experimental (~2=E2=80=933=C3=97 slower than HotSpot), and = Groovy leans heavily on invokedynamic, reflection, and runtime class genera= tion, so expect some compatibility rough edges.</li></ul><div><br></div></d= iv><div><br></div><div>Paolo</div></div><br><div class=3D"gmail_quote"><div= dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 3, 2026 at 2:51=E2=80=AFAM Jo= chen Theodorou <<a href=3D"mailto:[email protected]" target=3D"_blank">b= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa= dding-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> </blockquote></div> --00000000000034de3e065829b5ef--