A new JEP was recently submitted to the security-dev mailing list proposing the depreciation of the Security Manager (for removal): https://openjdk.java.net/jeps/411.
I think that going forward the combination of lack of support for the Security Manager in the openjdk, as well as the lack of security it actually offers, make it unsuitable for continued use sandboxing code execution in threadtear.
There are some alternatives that should be considered:
A JVMTI agent could be used to listen to events such as MethodEntry. These events would offer much greater power for preventing malicious code paths. Downside is that it would require development, maintenance and cross compilation of native code. Could also be problems with supporting multiple jvm versions and vendors.
A custom JVM implementation could be used to run the code. I am currently developing a java virtual machine implementation written in java which could be used for this purpose. Downsides are that this would require significant maintenance to ensure compatibility with obfuscated code, and ensure that the JVM cannot be fingerprinted and identified as a (fake?) jvm. It would also require maintenance to support future java versions.
Bytecode of methods that are to be executed could be analysed and rewritten to ensure no malicious behaviour. Method calls could be instrumented to first call a method that checks the arguments cannot lead to malicious code execution. Downsides are that this would be hard to do if any dynamic execution is employed, e.g. reflection or invokedynamic.
Hello.
A new JEP was recently submitted to the
security-devmailing list proposing the depreciation of the Security Manager (for removal): https://openjdk.java.net/jeps/411.I think that going forward the combination of lack of support for the Security Manager in the openjdk, as well as the lack of security it actually offers, make it unsuitable for continued use sandboxing code execution in threadtear.
There are some alternatives that should be considered: