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