JEP 411: Sandboxing v's LOTJ (language other than Java) running on top of Java class libraries / JVM.

Peter Firmstone peter.firmstone at zeus.net.au
Sat Jul 24 23:30:09 UTC 2021


I have established it's not practical to implement agents to intercept 
Java class libraries (Not the JVM) to guard access, such as class 
loading, properties, IO, etc.

It's also not practical to construct a Sandbox using ClassLoader, as has 
been suggested:

 1. We would have to prevent access to java.lang.Class, to prevent code
    escaping the sandbox, this is far too restrictive.
 2. It isn't practical to dynamically grant access, from within a sandbox.
 3. The sandbox is an all or nothing approach.
 4. The sandbox isn't an authorization layer.

Clearly Java in future, will be a zone of implicit trust, similarly to 
how we use C today from Java.

We need a "safer" language than Java, just like Java was a "safer" 
language than C.

This "safer" language would then allow authorization access controls, 
for network, file, class loading, data parsing, etc.

Rather than a sandbox, it just needs to be safer, with the ability to 
allow access to the underlying Java / C / etc, to trusted / 
authenticated / verified entities.

If anyone has any ideas regarding suitable languages, I'd be very 
interested to hear your thoughts.

-- 
Regards,
  
Peter Firmstone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210725/bf0c8ef2/attachment.htm>


More information about the security-dev mailing list