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
> > >
> > >
> >

Reply via email to