CODEWITHSUNDEEP
javajvmjrubyjythonsandbox
Jono Brogan
Jono Brogan

Reputation: 360

Java sandbox for running multiple JVM platform languages

I am currently evaluating the feasible of a project to build a small web application that provides a REPL programming environment similar to that of tryruby and codeacademy and have been looking at the possible solutions to evaluate the user submitted code safely, regarding a server side solution I have read that the JVM provides the best sandboxing environment as it has built in security measures.

I read about the JavaTM Scripting API and that it can be used to evaluate code on various script engines/ interpreters such as rhino(javascript), jruby, jython and Quercus(php). Would it be possible to have a single server running the JVM to evaluate user code in serval different languages? Would this be at all efficient? If not what other options do I have?

Upvotes: 1

Views: 379

Answers (1)

Stephen C
Stephen C

Reputation: 718758

Would it be possible to have a single server running the JVM to evaluate user code in serval different languages?

Yes it would be feasible.

Would this be at all efficient?

I'm not sure why efficiency is a particular concern. It strikes me that running small examples for remote users does not require efficiency. Either way, my take is that it should be efficient enough.

However, the real concern here is that this kind of service invites various kinds of abuse:

  • People may be inclined to try and break your sandbox. And if you haven't implemented it properly (or if they can exploit some unpatched security flaw) they may succeed, and get into the rest of your system.

  • People may be inclined to launch denial of service attacks. There are various things that a security sandbox can't deal with; e.g. creating large data structures to trigger GC overload and OOMEs, creating lots of threads, infinite loops.

  • Or they may do some of the above accidentally.

If you implement a service like the one you are proposing, you will need a strategy to deal with these things.

FOLLOWUP

Regarding the comment on efficiency, my thought was that loading an entire interpreter into memory for possibly a single line of code, may not be the best approach to take?

Well the normal way that you implement a service on a JVM-based language is to run multiple requests in the same JVM instance. If you did that here you wouldn't be loading the interpreter each time. You'd just be reinitializing it.

But either way, you are better off leaving the efficiency problem to later.

Upvotes: 1

Related Questions