Hi Paul, thank you for your answer. About sandbox, what do you think about [3] or [4]? Both seems to be quite active, license-compliant and available from Maven Central.
Also, do you have any example of ImportCustomizer / SecureASTCustomizer to start from? I have only found [5] so far. Regards. [3] https://github.com/dalet-oss/groovy-sandbox [4] https://github.com/craftercms/groovy-sandbox [5] https://github.com/jenkinsci/script-security-plugin/blob/master/src/main/java/org/jenkinsci/plugins/scriptsecurity/sandbox/groovy/RejectASTTransformsCustomizer.java On 2025/08/16 21:31:36 Paul King wrote: > Step 4 in your reference [2] is the key. > > You can provide an ImportCustomizer and a SecureASTCustomizer to limit > imports and prohibit statements like "System.exit()". As mentioned in that > article, that doesn't stop folks potentially using reflection or other > tricks to execute the exit() statement. You can start trying to lock down > such statements too. It becomes increasingly tricky to block all of the > tricks without crippling what your users may legitimately want to execute. > So, having a sandbox is the next step. > > Using the security manager with a policy file, also mentioned in that > reference, has gone out of vogue and isn't supported in the latest JDKs. > You'd more typically use a VM these days and set up a machine where it > didn't matter if a script somehow managed to read the /etc/passwd file (or > whatever). > > We have been meaning to document best practices for a sandbox environment > but haven't found the cycles yet. We'd be super keen to work with you to > write something up if you make progress. > > Cheers, Paul. > > > On Sat, Aug 16, 2025 at 5:13 PM Francesco Chicchiriccò <ilgro...@apache.org> > wrote: > > > Hi team, > > Syncope is offering the possibility to extend / customize the base > > behavior on every deployment by allowing to provide custom implementations > > of a few Java interfaces; such implementations can be provided either as > > Java or Groovy classes [1], with the latter being particularly attractive > > as the machinery is set for runtime reload. > > > > I was wondering if there is any best-practice available to limit what > > could be done by Groovy classes (e.g. System.exit, spawning new processes, > > etc.). > > I found [2] and a few other references which looks anyway either old or > > not for general purpose. > > > > Can you suggest something else? > > > > TIA > > Regards. > > > > [1] > > https://syncope.apache.org/docs/4.0/reference-guide.html#implementations > > [2] > > https://levelup.gitconnected.com/secure-groovy-script-execution-in-a-sandbox-ea39f80ee87 > > > > -- > > Francesco Chicchiriccò > > > > Tirasa - Open Source Excellence > > http://www.tirasa.net/ > > > > Member at The Apache Software Foundation > > Syncope, Cocoon, Olingo, CXF, OpenJPA > > https://about.me/ilgrosso > > > > >
