Let's Talk: Code Permissions

[gudenau]

Let's Talk: Code Permissions

[asiekierka]

The two key things that probably should be done regardless if we even want to start considering this:

• (a) forbid loadLibrary calls by default,
• (b) make reflection/MethodHandles only work through a Loader-defined interface which ensures you don't overstep your boundaries and reflect into the JVM (and, convienently, handles remapping? :D).

That way, we bump the amount of effort to getting non-JVM-controlled code running significantly, requiring an exploit in the JVM, LWJGL or STB libraries.

[i509VCB]

So discussion with Player on this. It sounds like a simple idea but it could cause issues:

Easily bypassed with unsafe, asm, badly made natives. So it only guards anything but the most naive cases. Also I have heard that apparently openjdk is considering dropping some of the security stuff in future versions or delegating it behind a command line argument.

The suggested solution here is to encourage use of a proper sandboxing solution on OS level for security and other user action. Mods are just like any other software. You have the same risks running an exe vs a mod.

[Prospector]

I don't see much of a point tbh. Perhaps for network activity but not much else

[Daomephsta]

If it did any more than asie suggested, I suspect it would cause more trouble than it's worth. An in-depth permissions and sandboxing system would probably confuse users, irritate modders, and eat a lot of development time (sandboxing is notoriously difficult, to my knowledge).

I don't think malicious mods are enough of a problem to call for this. The incident with Tinkers is the only significant malware incident I'm aware of. Most malware mods are found on rehosting sites, and are infected copies of safe mods. Safe mods are almost all hosted on CurseForge. It's probably more effective to educate users about safe download locations, and potentially encourage signing mod .jars, so copies that have been tampered with can be identified (I think this is easier than sandboxing?).

[JamiesWhiteShirt]

Are there any documented incidents where a permission module would have helped?

[gudenau]

Malware has been developed for Minecraft and distributed in mods mirrored on websites. A year or two back there was one for Tinker's that dropped executable to disk and ran them outside of the sandbox.

[asiekierka]

I'd say many of those reach a bit far; generally, I think we would only want to block things which go beyond the Minecraft engine's area of interest (access outside of gameDir/accessDir, raw fs/network/uncontrolled reflection, but not necessarily having configs or general data storage).

[gudenau]

Could also just set it up so that only signed jars are allowed to do "dangerous" things as well.

[modmuss50]

Honestly I don’t think it’s needed, as it’s almost impossible to make it secure. People will find ways to get around it.

I could work better in a way where a mod says what it plans to do and asks the user if they are happy with it. But fabric would not enforce it.

[Pyrofab]

Just a reminder that some mods (e.g. PSI) like to put global config files outside the game directory, so refusing filesystem access could be quite annoying.

[asiekierka]

I've started looking into it. A notable thing to make sure of is that there's a way to make (a) and (b) only apply to modded code and not Minecraft/library code (Gson, LWJGL, etc.) - it appears the most likely way is via (slow) stacktrace lookups. It remains to be seen how big an effect that has on performance (that is, how often both use methods such as .setAccessible(true) which propagate into a security check).

[gudenau]

What about ProtectionDomains?

[asiekierka]

Didn't come to mind! I'll test it and see what happens.

[gudenau]

Yeah, you are supposed to use those. Part of the JVM and allows for faster access checks. :-P

[ChloeDawn]

I like the idea of only allowing signed jars to do anything potentially dangerous

[liach]

Code permission/sandboxing is definitely a potential role of fabric loader (as this stuff may be mixin/entrypoint related); we should list clearly what we desire to accomplish (e.g. block access to parent directory of game dir; signature verification).