Hacker News Reader

Comment by kllrnohj | Hacker News Reader

Unless they add multi-processing to the mod system, they can't. You can't "sandbox" a Java class like that. You can't deny it access to JNI. You can't deny it access to java.io. You can have the host OS do this, of course, but now we're talking something far, far more complex than any mod system ever.

Which is, frankly, an absurd demand.

Mojang should have a mod API, but that won't do diddly squat to improve saftey. Don't execute code if you don't want that code to run.

View on HN

Of course you can deny it access to JNI [1]. The Java platform has had this built in since forever. This is how applets work. Aside from sandbox exploits classes in Java can be locked down so much that they can pretty much only allocate memory and burn cycles.

[1] http://docs.oracle.com/javase/7/docs/api/java/lang/SecurityM...

Java Applets? That thing that had exploits like clockwork?

Yeah, that worked great

Regardless did you even bother looking at the documentation of SecurityManager? That would be a disaster to try and support. It can't clamp down per-library, it's all about current thread. Mods run in the same thread, they have to. So now you're suggesting that every. single. call into or out of a mod is guarded manually by updates to a permission manager that you are preventing the mod from modifying via reflection through... magic? Yeah, there's no way in hell that would ever work.

We execute untrusted HTML all the time. (And javascript.)

You might argue that HTML is not a general purpose language, and that is exactly true. That's what makes it easier to sandbox.

HTML isn't code, you can't execute it.

And JavaScript runs in a VM designed specifically to handle untrusted code.

Neither applies in the slightest to the Java VM or Minecraft mods which, by definition, occupy the same process space with the same permissions as Minecraft itself. It is not a web browser, it does not have process sandboxing, it does not have a seperate VM specifically for mods, etc...

> HTML isn't code, you can't execute it.

That's exactly a point I wanted to make. See https://www.usenix.org/legacy/publications/login/2011-12/ope... and http://langsec.org/papers/langsec-tr.pdf

To be fair, browsers spend a lot of effort on making sure their sandbox works as intended.

When they have a defined modding API, they could expose it to a scripting language like JS or Lua that's potentially even easier to sandbox, too.

Reply on news.ycombinator.com