You may be interested in tweakflow [1] in that case -- it's a scripting language that doesn't allow arbitrary operations (as opposed to Groovy etc) and can even limit the execution time [2]
I would probably not set up a security manager to monitor operations, as any situation which called for a security manager could be targeted more precisely using a Java agent running Byte Buddy to do interception. [3] [1] https://twineworks.github.io/tweakflow/index.html [2] https://twineworks.github.io/tweakflow/embedding.html#limiting-evaluation-time [3] https://tersesystems.github.io/terse-logback/guide/instrumentation/ On Sat, Apr 17, 2021 at 1:24 AM Anthony Vanelverdinghe <d...@anthonyv.be> wrote: > Actually I think GraalVM can already do this today, since the mentioned > API is for use with any guest language, and Java can now run as a guest > language [1]. Note that this is also reminiscent of the `java.scripting` > module (JSR 223), which also has a `ScriptContext` class, but I'm not sure > what the long-term plans are for that API. > > Imho, any new mechanism should be tightly integrated with the module > system. In fact, Panama already has the concept of "restricted operations". > Currently, access to these operations is enabled with a simple system > property, but, quoting from [2]: > > We plan, in the future, to make access to restricted operations more > integrated with the module system; that is, certain modules might require > restricted native access; when an application which depends on said modules > is executed, the user might need to provide permissions to said modules to > perform restricted native operations, or the runtime will refuse to build > the application's module graph. > > Kind regards, Anthony > > [1] https://github.com/oracle/graal/tree/master/espresso > [2] > https://htmlpreview.github.io/?https://github.com/openjdk/panama-foreign/blob/eb2f956aef1d039a0d364eb69ed91bb9293c4387/doc/panama_memaccess.html > > On Friday, April 16, 2021 23:37 CEST, Mark Raynsford <org.open...@io7m.com> > wrote: > > > On 2021-04-16T17:02:06 -0400 > > Sean Mullan <sean.mul...@oracle.com> wrote: > > > > > > That said, I think it is worth exploring (in this JEP) or another JEP > > > ways that we might think about that could help provide DiD protection > > > for network and file access. This is an opportunity to look at the > > > problem with a fresh set of eyes, w/o the existing complicated > > > infrastructure and APIs that encompass the Security Manager. > > > > This is something that has interested me in the past. Although I'm not > > working on anything currently that would need it, I've often come up > > against this sort of thing in application plugin systems. That is, > > users have an application that they do trust and they want to load > > plugins into it that weren't written by the application author and that > > they do not necessarily trust. > > > > Languages such as Lua handle this fairly well by having programmers > > create lightweight scripting contexts for running scripts inside a > > host program. The guest scripts: > > > > * Can't call I/O methods if they aren't given access to a > > a table of I/O methods. This actually extends to not being > > able to call foreign code at all if access isn't provided; > > scripts are limited to objects within the provided table. > > > > * Can't use unbounded heap space if a custom allocator is > > handed to the script context. > > > > * Can't go into an infinite loop if instruction count limits > > are enabled (the interpreter is pre-empted or halted if it > > reaches N instructions, where N is some value configured > > by the host). > > > > * Can't create new threads. > > > > * Are probably memory-safe, assuming a lack of bugs in the > > Lua interpreter. :) > > > > Under those constraints, it's pretty tough to do anything disruptive > > even if you're trying to. Without access to I/O functions and other > > foreign code in the global table, you're pretty much limited to doing > > arithmetic. Quietly. And not too much of it. > > > > Similar constraints are available for code running under GraalJS [0] > > and that's certainly achieved without a security manager. > > > > I'm more inclined to think something that is rather blunt and brute > > force can be made to work well than something extremely fine-grained > > like the security manager. The blunt and brute force method says > > "put all this small piece of untrusted code in this box, and it's > > not allowed to do anything other than the very few things I say it can, > > and the code outside of the box is allowed to do whatever it could > > normally do". The security manager more or less has to have a large > > manually-maintained policy for the entire application and everything in > > it, and I think that's where it falls over. > > > > [0]: > https://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/Context.Builder.html > > > > -- > > Mark Raynsford | https://www.io7m.com > > > >
