4 ms·
It's deprecated for removal.[0] [0] https://openjdk.org/jeps/411 https://openjdk.org/jeps/411
by prosody 3y ago
It's deprecated for removal.[0]
[0] https://openjdk.org/jeps/411 https://openjdk.org/jeps/411
- kaba0 3y agoGraalVM has Isolates that can do this on a much more fine-grained level and with multiple languages (it can also run LLVM-languages now).
- mlinksva 3y agoI'd seen that https://www.graalvm.org/latest/security-guide/polyglot-sandbox/ https://www.graalvm.org/latest/security-guide/polyglot-sandb... is JavaScript-only at this point, I guess it must build on https://www.graalvm.org/latest/reference-manual/embed-languages/#polyglot-isolates https://www.graalvm.org/latest/reference-manual/embed-langua... and one could roll their own for any language? Is there a good example, doc, or is it even a thing, to use GraalVM Isolates to defend against Java supply chain attacks, nevermind other languages? I guess it might be possible, going by a comment on another thread https://news.ycombinator.com/item?id=38278131 https://news.ycombinator.com/item?id=38278131 but require careful construction of anything you'd want to have only the capabilities you pass to it? (Naive questions, apologies, I should really learn by trying it out instead!)
- kaba0 3y agoI believe it should work with any other Graal language (currently, JS, Python are the bigger ones and Sulong can run LLVM bytecode. There is also Espresso, which runs “java on top of java”, making it also eligible for these security boundaries). I don’t think it is too commonly used yet, but yeah, it can even do stuff like limit CPU usage within an isolate, so it should be more than possible to limit the scope of such an attack.