Re: Best practice to limit the capability of Groovy classes

FYI we have created

https://github.com/Tirasa/groovy-security-sandbox

by forking=20

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/8b08c4d5785599a0e38830dcff89738b93f0=
2a16

and ConnId (supporting framework for provisioning) in

https://github.com/Tirasa/ConnId/commit/bc4f4a3b3a424c2f1431fafe0a507f4a5ff17=
ba7

Regards.

On 2025/08/17 07:12:09 Francesco Chicchiricc=C3=B2 wrote:
> Hi Paul,
> thank you for your answer.
>=20
> About sandbox, what do you think about [3] or [4]? Both seems to be quite a=
ctive, license-compliant and available from Maven Central.
>=20
> Also, do you have any example of ImportCustomizer / SecureASTCustomizer to =
start from? I have only found [5] so far.
>=20
> Regards.
>=20
> [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/mai=
n/java/org/jenkinsci/plugins/scriptsecurity/sandbox/groovy/RejectASTTransform=
sCustomizer.java
>=20
> 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 <ilgr=
[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 implementati=
ons
> > > of a few Java interfaces; such implementations can be provided either as
> > > Java or Groovy classes [1], with the latter being particularly attracti=
ve
> > > 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 process=
es,
> > > 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-sa=
ndbox-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
>=20