JEP411: Missing use-case: Monitoring / restricting libraries

[Mark Raynsford]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210416/796b8506/attachment.sig>