Re: Best practice to limit the capability of Groovy classes

--000000000000d37961063c823b5b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM Francesco Chicchiricc=C3=B2 <ilgros=
[email protected]>
wrote:

> Hi team,
> Syncope is offering the possibility to extend / customize the base
> behavior on every deployment by allowing to provide custom implementation=
s
> 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
>
>

--000000000000d37961063c823b5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Step 4 in your reference [2] is the key.<div><br></div><di=
v>You can provide=C2=A0an ImportCustomizer and a SecureASTCustomizer to lim=
it imports and prohibit statements like &quot;System.exit()&quot;. As menti=
oned in that article, that doesn&#39;t stop folks potentially using reflect=
ion or other tricks to execute the exit() statement. You can start trying t=
o lock down such statements too. It becomes increasingly tricky to block al=
l of the tricks without crippling what your users may legitimately want to =
execute. So, having a sandbox is the next step.</div><div><br></div><div>Us=
ing the security manager with a policy file, also mentioned in that referen=
ce, has gone out of vogue and isn&#39;t supported in the latest JDKs. You&#=
39;d more typically use a VM these days and set up a machine where it didn&=
#39;t matter if a script somehow managed to read the /etc/passwd file (or w=
hatever).</div><div><br></div><div>We have been meaning to document best pr=
actices for a sandbox environment but haven&#39;t found the cycles yet. We&=
#39;d be super keen to work with you to write something up if you make prog=
ress.</div><div><br></div><div>Cheers, Paul.</div><div><br></div></div><br>=
<div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"=
gmail_attr">On Sat, Aug 16, 2025 at 5:13=E2=80=AFPM Francesco Chicchiricc=
=C3=B2 &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi tea=
m,<br>
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 Gr=
oovy classes [1], with the latter being particularly attractive as the mach=
inery is set for runtime reload.<br>
<br>
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.)=
.<br>
I found [2] and a few other references which looks anyway either old or not=
 for general purpose.<br>
<br>
Can you suggest something else?<br>
<br>
TIA<br>
Regards.<br>
<br>
[1] <a href=3D"https://syncope.apache.org/docs/4.0/reference-guide.html#imp=
lementations" rel=3D"noreferrer" target=3D"_blank">https://syncope.apache.o=
rg/docs/4.0/reference-guide.html#implementations</a><br>
[2] <a href=3D"https://levelup.gitconnected.com/secure-groovy-script-execut=
ion-in-a-sandbox-ea39f80ee87" rel=3D"noreferrer" target=3D"_blank">https://=
levelup.gitconnected.com/secure-groovy-script-execution-in-a-sandbox-ea39f8=
0ee87</a><br>
<br>
-- <br>
Francesco Chicchiricc=C3=B2<br>
<br>
Tirasa - Open Source Excellence<br>
<a href=3D"http://www.tirasa.net/" rel=3D"noreferrer" target=3D"_blank">htt=
p://www.tirasa.net/</a><br>
<br>
Member at The Apache Software Foundation<br>
Syncope, Cocoon, Olingo, CXF, OpenJPA<br>
<a href=3D"https://about.me/ilgrosso" rel=3D"noreferrer" target=3D"_blank">=
https://about.me/ilgrosso</a><br>
<br>
</blockquote></div>

--000000000000d37961063c823b5b--