Let's Talk: Security and JSR223
LemmaEOF opened this issue · 7 comments
JSR223 is the best tool we have for running scripts for things like Cotton Tweaker. However, its sandboxing capability is somewhat limited. Data packs, luckily, have the advantage of only ever being run server-side; a malicious server admin can't write a script to profile players' computers. However, that still doens't prevent users from being profiled by data packs run in single-player worlds. Ultimately, the reliability of Cotton tweakers almost more than that of mods, since you can actually see what's in a script without decompiling it. However, that doesn't mean we should leave the floodgates open for whatever people want. Should we add a ClassShutter to Tweaker-run scripts, and if so, what rules should we have so that the system keeps its extensibility?
For an idea of shutter rules, does blocking out all classes except ones in the io.github.cottonmc.cotton.tweakers package and/or with the word Tweaker in the class name sound good?
I don't think this is the solution. If some script starts profiling the player in singleplayer, that's the player's concern, and he can choose to remove the script, or decide it's not a big cause to him.
By making that choice, it removes from the player.
Sandboxing for JSR223 - and java in general, without explicitly running a hand-rolled interpreter - is unlikely to be effective.
ah yeah, it looks like the ClassShutter from Rhino didn't make it into Nashorn/JSR223.
It doesn't look like the ClassFilter is accessible to ScriptEngineManager or ScriptEngine being called. I can't find any methods in any of the related ScriptEngine code, and the Oracle docs on ClassFilter say it's specific to Nashorn, when the whole point of the tweaker system is that you can use any JSR223. The closest thing I can get access to is passing a custom ClassLoader, but I am not writing a custom class loader just for this.