What Java classes/packages are safe to whitelist in a security sandbox?

Question

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.

Answer 1

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.

Answer 2

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.