Hi! 
I’m working on a ‘sandbox’ solution for game modding and I was wondering which classes or methods dangerous if misused. Note that by “dangerous” we’re not referring to the game’s integrity but to the system’s integrity, security and user privacy.
System access:
Remote connection:
Resource loading:
Resource saving:
Devices access:
Have you looked at the Godot Mod Loader before re-inventing the wheel?
Yup, and it’s not a matter of reinventing the wheel! I currently implement the loader in my project and it is a marvelous tool. However, it doesn’t suffice my intent of downloading custom content on the go, since my game could benefit from that.
Thus, the need of sandboxing which also isn’t and won’t probably be provided in the near future by GML. I am also knowledgeable of the complexity and possible security risks of implementing this kind of custom content download system, thus why I am discussing this post here to take better informed precautions.
How are you planning on sandboxing them?
Sandboxing is quite hard, there’s a lot of ways to workaround whatever limitations you put in place. It would be easier if you just whitelist the few classes you want to support instead of blacklist the ones you don’t want to.
Of the top of my head:
ClassDB lets you interact with all the classes in the engine (create new instances, call functions, interact with objects,…)
Engine lets you access the singletons by name like var os = Engine.get_singleton("OS")
Anything related to networking like TCPServer or anything extending StreamPeer
The DisplayServer lets you mess with mouse, show native alerts, mess with the window,…
GDScript lets you… well… create scripts from strings. For example:
extends Node
var payload = """
extends Node
func _init() -> void:
var os = Engine.get_singleton("OS")
os.alert("POWNED!")
os.crash("bye bye")
"""
func _ready() -> void:
var script = ClassDB.instantiate("GDScript")
script.source_code = payload
script.reload()
set_script(script)
GDExtension which lets you skip any protection I can think of. You’ll probably need a custom build of the engine to disable it (I’m not sure how)Yup, that’s the approach. I was just interested in marking methods that are explicitly dangerous, but yes, I was planning on the best practice of whitelisting not blacklisting. It’s going to be a pretty bare bones solution, still trying to maintain security:
Nothing to do with embedded processes and things like godot-sandbox, just plain filtering of text in .tscn, .gd and .json files. The idea is to allow for really simple functions like maybe connecting some signals, moving a node or changing a property. I would still try to offer most functionality directly through the props from the editor. My objective is rather to provide a way of generating user created content than to offer actual modding capabilities.
For what I would call ‘actual modifications’ of the game, I’m still going to use GML. However, it won’t be enrolled in the auto-download feature. Mod users would be on their own, which really doesn’t bother me that much, that’s the risk we all expose ourselves to in Minecraft.