Hmm ... how about educating your developers in what can be called, and what shouldn't ? As far as I know there are very few or no software languages that supports such things. All that is needed is experience, experience, and experience!
Tommy Svensson to...@natusoft.se (mailto:to...@natusoft.se) På 17 augusti 2025 till 09:12:09, Francesco Chicchiriccò (ilgro...@apache.org (mailto:ilgro...@apache.org)) skrev: > 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 > > > > > > > >
