FYI we have created https://github.com/Tirasa/groovy-security-sandbox
by forking https://github.com/jenkinsci/groovy-sandbox with some goodies from the sibling fork https://github.com/craftercms/groovy-sandbox and some polish. The library was applied to Syncope in https://github.com/apache/syncope/commit/8b08c4d5785599a0e38830dcff89738b93f02a16 and ConnId (supporting framework for provisioning) in https://github.com/Tirasa/ConnId/commit/bc4f4a3b3a424c2f1431fafe0a507f4a5ff17ba7 Regards. On 2025/08/17 07:12:09 Francesco Chicchiriccò wrote: > 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 > > > > > > > > >
