larsiusprime
Add security measures or sandboxing support
Given that:
- modders will be given access to objects, like DisplayObjects
- DisplayObjects have access to stage
- stage has access to pretty much everything (e.g. the main app is on the stage, and all references therein)
- these are runtime accesses, so private scoping does not apply
It should be assumed that scripts may control any property / function of the application... or we'll need some framework for detecting / restricting access to certain properties / functions from the hscript context.
Example code (note that Reflect and Type aren't available by default, but trace is, and they lend visibility in exploration / hacking):
var obj = bee.stage.getChildAt(0).getChildAt(0);
var cls = Type.getClass(obj);
trace( Type.getClassName( cls ));
trace( Type.getClassFields( cls ));
trace(Reflect.fields( obj ) );
// also Type.resolveClass could potentially give access to all types
Honestly, I'm not sure there's anything that can be done about this. Probably just put a big red flag that this is primarily meant for games and that if anything sensitive is being done with your app you should NOT use polymod.
Other things to consider, though:
- Advise as a best practice to disable achievements or whatever in things like Steam API if modding is enabled.
- Advise as a best practice in multiplayer games to NEVER TRUST THE CLIENT. Modding doesn't change this equation, just makes it more obvious.
- The REAL security concern is filesystem access. We might need a sandbox for this? I'm wondering if something like PhysicsFS could help.
Ah, well, as long as you don't give them Type or Sys or File, or anything with a reference to those classes... presumably they couldn't directly access the filesystem.
They do only get what you give them, but sometimes you forget that your objects have tons of references lying around.
I think, if we went deep (perhaps for hxcpp only), we could enable strict access mode during hscript calls (or even check if an hscript context is on the call stack) at the hxcpp/VM level to literally deny access to certain properties or functions...
But yes, as you say, step 1 is mostly about communicating the issue.
Right, even if they don't have access to Sys or File, directly, they do have access to whatever daisy chain lets them reach a function that does have access to that stuff. And I think trying to analyze that into safety is going to be way beyond the average game developer's abilities. And I'm not sure we can really do it statically, either. Your method sounds promising but I kind of expect to leave out an edge case.
The only way to REALLY be able to guard against the "mod that deletes your hard drive" attack, is to sandbox the entire application. Make it so that any filesystem call that tries to write outside of the sandbox is just a hard fail. Do you think that's reasonable?
This is always going to be "modder beware" to some extant but I feel we can make some basic safeguards?
Also, just thought of this: this is a side benefit of #7 -- if we can print out the entire mod surface API, it serves as a good reality check for what you're really exposing to the user.
This is a serious and difficult problem with scripting support.
We might be able to directly intercept attempts to calls for file read/write access HaxeFoundation/hscript#60. The problem is that this only intercepts DIRECT calls and not indirect ones.
Another stopgap option could be to add a compile-time error like so:
ERROR: You attempted to include 'Sys' in your @:hscript annotation at CLASSNAME.FUNCNAME#POS. This is a known privileged . Set the define POLYMOD_UNSAFE_SCRIPTING = "true" to disable this.
Here is my current denylist:
Reflect: Allows unfiltered access to other types.Type: Allows unfiltered access to other types.Sys: Lets you do lots of invasive system stuff.sys.FileSystem: Lets you read, write, or delete files.File: Lets you read, write, or delete files.haxe.Http: Allows creating HTTP requests that send data about the user's computer to a malicious actor.
