Re:?==?utf-8?q? JEP411: Missing use-case: Monitoring / restricting libraries

[Anthony Vanelverdinghe]

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.openjdk at io7m.com> wrote: 
 
> On 2021-04-16T17:02:06 -0400
> Sean Mullan <sean.mullan at 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
>