Re: Groovy sandboxing

On 8/3/26 21:40, ski n wrote:
[...]
> This library however isn't really a sandbox, but works more with 
> intecepton, than really with isolation. Though you can use blacklisting/ 
> whitelisting approaches, but those are not long term solutions.
> I think better solutions have already been proposed here.
> 
> To add to this information,  Gilles Duboscq, researcher at Oracle writese:
> 
> "For JVM languages there is Espresso <https://www.graalvm.org/latest/ 
> reference-manual/espresso/> which is a Truffle implementation of the JVM.
> 
> Sandboxing it presents some challenges though, especially around native 
> code: by default espresso uses the standard java and native code of 
> OpenJDK for its standard library.
> 
> To truly sandbox espresso, this native should either itself be sandboxed 
> or not used as all and Truffle APIs used instead.
> 
> We did some experiments in that direction already though, with a "no- 
> native" mode that can already run some simple workloads.
> 
> Combining this with Polyglot Isolates could be a path forward for using 
> this sandboxing with JVM languages."
> 
> All of our Groovy are dynamically run, so we use JIT, but native is also 
> something to consider.
Paul is currently trying to improve the usage as Groovy for native 
compilation.

I spend some time looking at Espresso and found a few things that are 
insteresting.

* Espresso and probably Truffel itself has a notion of host code and 
guest code.
* Espresso replaces a lot of JDK calls in the guest with its own code. 
This is done using substitutions, not by modifying the JDK
* Espresso builds it list of substitutions at build time of Espresso
* guest code can not and is not supposed to influence that mechanism

And for Groovy as guest going the way of substitutions this concludes to 
Groovy would have to be extending Espresso with Substitutions in 
Espresso itself, registering them at build time of Espresso.

So unless we essentially form Espresso or make a Groovy variant of 
Espresso in which we add our own Substitutions this would not work. 
Though I do think it would be possible to do this. In the end I think we 
would have to change the bytecode of the SubstitutionsCollector, which 
is a generated class. Licensing could become an issue, though.

The question is what we would even achieve? All method call operations, 
including the invokedynamic we use could be replaced at runtime with 
Espresso/Truffle logic and nodes. Espresso even replaces calls to native 
methods. Then any runtime compiled or precompiled Groovy program/script 
run as guest would be affected. Essentially that is the Jenkins idea, 
just on a different level.

What this solution would not be able is of course to limit VM parameters 
like memory consumption. The guest can be seen as running in a 
lightweight JVM, which is the one that would have to be restricted from 
using too much CPU/Memory.

And while the Espresso approach would be a more complete solution then 
the Jenkins idea it made me think that we probably have everything we 
need to achieve something similar. Almost all significant calls go 
through out invokedynamic mechanism, which means there is a central 
method, that is called to provide the JIT with a MethodHandles graph, 
used to actually do the method execution. That method is called a 
bootstrap method (just explaining for people that have no idea how 
invokedynamic works). The logic behind the bootstrap method is a runtime 
implementation detail and changing this would not require changes to 
Groovy code. We could then in theory implement some kind of 
restrictions. Currently supported would be method calls, property get, 
and extended casts.

But it does not solve all cases, not even all cases of method calls. 
Static compilation bypasses this. AST Transforms could add bytecode that 
implements normal method calls (that is part of what static compilation 
does) and thus bypass this. Library code is not under our control with 
this, unless it is written in Groovy. If you somehow manage to spawn a 
Groovy in Groovy (technically possible with some class loader magic) you 
could probably bypass this. Even if you forbid static compilation, 
precompiled code with static compilation would be like any other library 
not affected, since this is on the compiler level and the compiler is 
already done for the library. And of course the worst thing, grapes 
could introduce who knows what (though that can be controlled). I am 
just trying to say, that this mechanism looks like it could do the Job, 
and probably would carry far, but by itself it is no reliable solution - 
unless you require everything in source, no library usage beyond what 
you control (especially no grapes), no AST transforms, beyond the 
builtin ones and no direct usage of Class loaders. Maybe that would then 
work out...

But there are probably holes in this shield. As I said the Espresso 
variant would be much more complete just by its nature already.

bye Jochen