Re: Best practice to limit the capability of Groovy classes

On 2025/08/17 08:19:24 Tommy Svensson wrote:
> 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 tha=
t supports such things. All that is needed is experience, experience, and exp=
erience!

I realize that the use case could not be clear to everyone.

So we have an organization somewhere (US company, Finnish university, whateve=
r) which uses Apache Syncope to build their own IAM system.
In one of the many identity flows they need, they realize that the options of=
fered by the system are not sufficient to cover their bizarre use case where =
- for example - the email address shall be calculated based on the first 3 le=
tters of surname + even letters of the first name + eye color + hair color + =
an ordinal based on the timezone + some random letters.
In such use cases, they have the chance to decorate the provisioning process =
by writing down a Java or a Groovy implementation of an interface, and loadin=
g such class into the system.
  * When it is Java, that shall be part of their Syncope-based project codeba=
se, is likely to go through a review process and will finally require a redep=
loy to become effective. Also important, every adjustment will require again =
to go through the same, redeploy included.
  * When it is Groovy, an administrator with enough entitlements can load the=
 class definition through the web UI and have it immediately available. Every=
 change to the class will be done again via a fancy syntax-highlighted textar=
ea.

This latter administrator is not exactly one of "our developers", but someone=
 which was granted by the organization as above to operate on the system.

Hope this clarifies.
Regards.

> Tommy Svensson
> [email protected] (mailto:[email protected])
>=20
> P=C3=A5 17 augusti 2025 till 09:12:09, Francesco Chicchiricc=C3=B2 (ilgross=
[email protected] (mailto:[email protected])) skrev:
>=20
> > 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 t=
o 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/m=
ain/java/org/jenkinsci/plugins/scriptsecurity/sandbox/groovy/RejectASTTransfo=
rmsCustomizer.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 t=
hat
> > > article, that doesn't stop folks potentially using reflection or other
> > > tricks to execute the exit() statement. You can start trying to lock do=
wn
> > > such statements too. It becomes increasingly tricky to block all of the
> > > tricks without crippling what your users may legitimately want to execu=
te.
> > > 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 environme=
nt
> > > 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=E2=80=AFPM Francesco Chicchiricc=C3=B2 <il=
[email protected]>
> > > wrote:
> > >
> > > > Hi team,
> > > > Syncope is offering the possibility to extend / customize the base
> > > > behavior on every deployment by allowing to provide custom implementa=
tions
> > > > of a few Java interfaces; such implementations can be provided either=
 as
> > > > Java or Groovy classes [1], with the latter being particularly attrac=
tive
> > > > 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 proce=
sses,
> > > > 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#implementati=
ons
> > > > [2]
> > > > https://levelup.gitconnected.com/secure-groovy-script-execution-in-a-=
sandbox-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