Re: Best practice to limit the capability of Groovy classes

Hi Paul,
thank you for your answer.

About sandbox, what do you think about [3] or [4]? Both seems to be quite act=
ive, license-compliant and available from Maven Central.

Also, do you have any example of ImportCustomizer / SecureASTCustomizer to st=
art 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/RejectASTTransformsC=
ustomizer.java

On 2025/08/16 21:31:36 Paul King wrote:
> Step 4 in your reference [2] is the key.
>=20
> 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.
>=20
> 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).
>=20
> 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.
>=20
> Cheers, Paul.
>=20
>=20
> On Sat, Aug 16, 2025 at 5:13=E2=80=AFPM Francesco Chicchiricc=C3=B2 <ilgros=
[email protected]>
> wrote:
>=20
> > 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-sand=
box-ea39f80ee87
> >
> > --
> > Francesco Chicchiricc=C3=B2
> >
> > Tirasa - Open Source Excellence
> > http://www.tirasa.net/
> >
> > Member at The Apache Software Foundation
> > Syncope, Cocoon, Olingo, CXF, OpenJPA
> > https://about.me/ilgrosso
> >
> >
>=20