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
pgpfVUgPu8JpE.pgp
Description: OpenPGP digital signature