What are the security risks I should guard against when running user-supplied Java code?

Question

Is there a comprehensive list of the security issues with running user-supplied Java code on a server? I\'m already

• using timeouts of 10 seconds
• runni

Answer 1

Looks like a very good start - Security Manager is essential for sandboxing a whole bunch of other stuff you don't mention explicitly (like preventing the user from disabling the Security Manager, of course, and being able to invoke arbitrary commands, or use native code, or get the OS to exec files etc). I assume you are starting from zero permissions and just granting the explicit permissions needed.

Security Manager can't deal with denial-of-service through excessive resource usage, but your other controls probably address this (prevent network connections, control disk usage, timeouts to prevent CPU hogging - if that's what you meant by timeouts).

You say "extremely limited filesystem permissions" - hopefully this also includes disk quota? are you running multiple untrusted processes, and do they share disk space? Running out of file handles might be an issue (not sure how these are managed for a limited account).

There are still occasional JVM vulnerabilities, so the risk depends on what else is on the server, and what the consequences of a problem actually are (how bad is it if you have to wipe the server?).

See also: Sandbox against malicious code in a Java application and Execute external Java source code on server - limit security and resources?

Answer 2

The question I'd ask myself is, 'How much do I trust the people, and how much do I trust that their code won't break my system?' In general, my answer would be not much, and not as far as I could throw 'em. But, off the top of my head, here are some things I would want to guard against.

• Infinite loops (timeouts help)
• Dodgy I/O operations (trying to read/write from/to directories they have no access to)
• Privilege escalation code (limiting the account to only be able to execute in a specific context, or with specific permissions is a huge plus)
• Creation of too many objects/removing memory (limiting available memory and/or resources is a plus here)
• Reading/writing from/to a socket and not releasing the resource
• Expecting input from STDIN, which may be problematic if the server is headless

There are plenty more to be wary for, so I would tread carefully. Safeguard each account and /home directory from one another as best as you can (a simple chmod 700 $HOME will often do it), and experiment with code that you would consider dodgy before deploying publicly. Once you're comfortable with how well the server holds up, allow others to test your server and see how well it goes.