Question about GraalVM sandboxing features

[fabrice-ducos]

Greetings,

I am developing a Java-based application in which I would like to provide the user with some server-side, restricted scripting facilities. Basically, I would like the user to access resources through dynamic language bindings, such as Python, Ruby, Javascript, Tcl or Lua (I am aware that Tcl and Lua are currently not officially supported, but I am ready to invest some time in the Truffle framework later if needed) without giving untrusted code access to the host filesystem, and to perform some classic restrictions (prevent the direct creation of processes and threads, the direct allocation of resources, limit the memory and cpu time used by users' scripts, etc). I am of course interested in runtime performance but my primary interest at the moment is sandboxing features, that are critical to the project.

I am completely new to GraalVM and I do have alternative sandboxing solutions, but it looks like that the GraalVM platform seems to provide exactly what I have been looking for in a simpler and more reliable way.

1. Can you confirm that GraalVM would be adapted to this use case?
2. Are the sandboxing features of GraalVM mature as of 2021? What worries me is the following quote from the official GraalVM documentation, that seems to claim that only Javascript bindings can currently be sandboxed in GraalVM:

The Polyglot API by default restricts access to certain critical functionality, such as file I/O. These restrictions can be lifted entirely by setting allowAllAccess to true.

Note: The access restrictions are currently only supported with JavaScript.

I am not sure to understand why (assuming the documentation is up-to-date) the GraalVM Context.Builder cannot be applied reliably to any Polyglot-supported language.

If both answers are positive, I will consider migrating to GraalVM for this project.

Thank you for your support and best regards

[matneu]

Hi Fabrice,

Wrt. to question 1: yes, this is definitely a use case we plan to support with GraalVM sandboxing features. As a matter of fact we already do that - if you go through the allow* methods in Context.Builder you can see that restricting filesystem access via a virtualized FS as well as disallowing creation of threads/processes is already supported.
Further, the enterprise resource limits allow you to put a cap on resources such as CPU time.

Wrt. to question 2: it is correct that at this point in time only Javascript fully supports restricting access entirely. Other language implementations still use native code e.g. for accessing files, but the plan is to move to managed code here as well, at which point access restrictions will also apply to those languages.

[fabrice-ducos]

Dear Matthias,

thank you very much for your clear answer. Those are very encouraging perspectives. I will seriously consider GraalVM.

Best regards