9

As part of a java powered game I am developing I plan to embed the Groovy (or possibly some other) scripting language to allow lower level mod support and a way for things such as dialogue and quest files to cause effects in the game world. However my purposes and the purposes of potential mod authors may vary, and if possible I'd like to avoid cutting out language features that aren't dangerous.

While my specific needs will of course vary from the public norm, I'm nevertheless curious if there is any generally agreed upon whitelist (however short) of java packages and classes that can be accessed without significant risk to the user.

Hawkwing
  • 663
  • 1
  • 5
  • 13
  • 1
    Is this code being run on a (e.g. your) server, or on the client machines? – Andrew Thompson Jul 22 '13 at 21:04
  • 1
    Not exactly the same, but this question may also prove useful to you if you have not already discovered it: http://stackoverflow.com/questions/6210045/bullet-proof-groovy-script-embedding – Trevor Freeman Jul 22 '13 at 21:33
  • @AndrewThompson the code will be run on client machines, however the concern is that I eventually would like to add multiplayer support and the ability to host modded servers. In this instance, I am looking into the feasibility of allowing such (3rd party) modded servers to provide required mod files (which may contain scripts) directly to connecting clients. This would of course need to be an "opt-in" process, but that makes it no less of a security concern. See [here](http://gamedev.stackexchange.com/questions/59390/how-far-should-i-go-in-securing-groovy-mod-scripts) – Hawkwing Jul 23 '13 at 12:56
  • *"..and the ability to host modded servers."* Then you even need to account for things as simple as `while(true);` - which will burn a lot of CPU cycles.. – Andrew Thompson Jul 23 '13 at 13:30
  • @AndrewThompson That sounds more like a concern to worry about if I was hosting servers that were executing user submitted code. What is happening is that clients running my game would be executing code provided by servers I do not control. I don't consider mods that simply cause slowdowns to be a security risk, however, as the user can simply end the program, remove the mod during their next launch, and continue on their way. – Hawkwing Jul 23 '13 at 13:56

3 Answers3

4

I'm nevertheless curious if there is any generally agreed upon whitelist (however short) of java packages and classes that can be accessed without significant risk to the user.

Yes there are white-lists, but I don't know how "generally agreed upon" they are. Community consensus is one way to vet a white-list, but you could also look at the experience of the list creators, and see if their process makes sense.

The Joe-E project came up with a "taming" of Java, and one of the parts of that was a white-list of the core libraries by class/method/field. For example, for StringBuilder, StringBuilder.safej says

# Manually verified.
class("java.lang.StringBuilder",
  static(constructor("StringBuilder()"),
    constructor("StringBuilder(CharSequence)"),
...
    method(suppress, "insert(int, Object)", comment("calls toString on arbitrary object")),

while Runtime.safej says

# auto-generated safej: default deny everything
class("java.lang.Runtime",
  static(method(suppress, "getRuntime()", comment("default deny")),
    method(suppress, "runFinalizersOnExit(boolean)", comment("default deny"))),
    ...

To understand taming, see the Joe-E paper which says:

4.2.1 Taming the Java class library

The Java library defines many static methods that have side effects on the outside world, as well as many constructors that create objects permitting similar effects. This is a major source of ambient authority in Java. For example, File has a constructor that will take a string and return an object representing the file with that name. The resulting object can be used to read, write, or delete the named file. Absent explicit access control by the Java security manager or the operating system, this allows any Java code full control over the filesystem. In Joe-E, we wish to ensure that code can only have access to a file if a capability for the file (or a superdirectory) is within that code’s dynamic scope.

Consequently, we must not allow the aforementioned File constructor in Joe-E’s global scope. We define a subset of the Java libraries that includes only those constructors, methods, and fields that are compatible with the principle that all privileges must be granted via a capability. We call this activity taming, because it turns an unruly class library into a capability-secure subset. The JoeE verifier allows Joe-E programs to mention only classes, constructors, methods, and fields in this tamed subset. If the source code mentions anything outside of this subset, the Joe-E verifier flags this as an error.

Taming helps eliminate ambient authority, because it ensures library methods that provide ambient authority are not accessible to Joe-E programs. We also use taming to expose only that subset of the Java library that provides capability discipline.

Mike Samuel
  • 118,113
  • 30
  • 216
  • 245
  • 1
    It'd be interesting if bytecode static analysis could white list bits of APIs. Tricky though. / `File` is an interesting one. It's supposed to represent a file path string. The danger comes with all the methods that have security checks. (There's another big danger in that `File` isn't actually immutable. – Tom Hawtin - tackline Jul 24 '13 at 08:57
  • @TomHawtin-tackline, some static flow-analysis could help debug a white-list by exposing missing sources, e.g. treat `new java.io.FileInputStream(String, String)` as a sink and make sure all the strings that reach it are recognized by the white-list as system resources. It's never going to be complete and probably won't be close to conservative given the presence of `java.lang.reflect.Method` and the ease of crafting [opaque predicates](http://en.wikipedia.org/wiki/Opaque_predicate). – Mike Samuel Jul 24 '13 at 14:04
  • 1
    Java reflection wont be on the whitelist. I can't remember whether Joe-E does this, but some object-capability languages support reflection through invites (code can create an object which has reflective access as if it was the code that created it - this can then be passed to more general code). Similarly, any code that uses reflection is going to be difficult to whitelist. Even code that uses mutable statics (e.g. a `private static final char[]`) is going to be highly problematic. – Tom Hawtin - tackline Jul 24 '13 at 16:03
  • @TomHawtin-tackline, I think you're right. IIRC Joe-E provides an attenuated alternative instead of taming. Mark Miller prefers dynamic type systems for many reasons, but one reason is that when an object is just a record, authors tend not to leak authority by mistakenly assuming that only the operators available via the static type are available. – Mike Samuel Jul 24 '13 at 17:04
1

I suspect you'll discover that instead of starting with a general-purpose programming language and figuring out how to give people access to that and make it safe, it's safer going the other way.

My approach would be to start with a domain-specific language and give it access to a sandbox - the aspects of your program's environment which you're willing and happy to have modders affect.

CPerkins
  • 8,968
  • 3
  • 34
  • 47
  • 1
    Alas, I have neither the time to develop my own domain-specific language, nor the clout to influence people to learn it simply to mod in my game. Unfortunately this is one of those cases where I have to make a 'best effort' attempt at security, in the interest of both the ease of adoption of the language for modders and my own ability to develop software with neither an unlimited budget nor time. – Hawkwing Jul 23 '13 at 14:15
  • @Hawkwing fair enough. Good luck. – CPerkins Jul 23 '13 at 21:09
  • Mike Samuel's answer mentions Joe-E, which is a safe subset of Java. That seems like a much better approach. However, it's the libraries which are difficult. – Tom Hawtin - tackline Jul 24 '13 at 08:53
0

I would try to emulate Java applet sandbox model. If the sandbox is safe enough to run arbitrary code from internet on my PC, it should be safe enough for your user scripts. Well, you probably don't want a user script to pop up some GUI window, so you'll need to restrict permissions more than applet sandbox.

ZhongYu
  • 19,446
  • 5
  • 33
  • 61
  • User-scripts are often written by naive developers and are reviewed less carefully than the application invoking them, so are more prone to [confused deputy](http://en.wikipedia.org/wiki/Confused_deputy_problem) vulnerabilities like script injection than the core codebase. – Mike Samuel Jul 22 '13 at 21:04
  • OP wants to support user scripts and wonders how to do it safely. – ZhongYu Jul 22 '13 at 21:08
  • Agreed. The OP is wise to try to grant enough authority to the user scripts to do their job but not much more because of the naivité of script authors and lower review and testing standards. – Mike Samuel Jul 22 '13 at 21:12