3

I'm working on an online environment that will allow users to execute custom Scala code (think of it like continuous integration). However, I want to prevent them from doing certain things, most notably file I/O and network calls. I will allow limited forms of these functions with a library that I will expose.

The naive approach would be to simply replace /^import.*$/ with the empty string. However, there are plenty of ways for nefarious folks to get around that, with classloaders and such. I want the users to only have access to a preselected "whitelist" of imports rather than having to rely on a (possibly incomplete) blacklist.

I still haven't decided whether I'm going to call scalac on the underlying OS with their files, or whether to use IMain to interpret the text. Obviously if one method makes my desired result feasible, I'll go with that one. Bonus points if your answer includes ways to

How can I effectively sandbox my users' code?

Ryan Kennedy
  • 3,275
  • 4
  • 30
  • 47
  • Thanks for asking this (back 4+ years ago). I'm having a similar need, in making sure two JSON-creating libraries (Casbah and spray.json) are not accidentally imported into the same scope (which leads to problems). So essentially, I'm trying to protect me from myself. :) – akauppi Dec 01 '14 at 12:06

1 Answers1

3

There are two different issues: compile-time and run-time sandboxing.

Runtime sandboxing can be accomplished by using Java Security and classloader restrictions - see e.g. How do I create a Java sandbox? and, more cautionary, Can I trust Java SecurityManager sandbox?. There's a lot more out there on this topic!

For Scala compile-time sandboxing, I have to defer. However, I wonder whether you need it. If the only people who try to use forbidden API's are those who are trying to break into your system, there's no reason to make their job easier by providing compile-time checking.

Community
  • 1
  • 1
Ed Staub
  • 15,480
  • 3
  • 61
  • 91
  • 1
    Wow, it never would have occurred to me that this problem has already come up in Java and has been solved. Good point that this is a JVM problem and not really a Scala-specific problem. Thanks for pointing me in the right direction! – Ryan Kennedy Mar 10 '14 at 18:55
  • @RyanMuller - One of the early killer apps for Java was Java applets - downloadable browser-based, sandboxed Java apps. Be warned that a major reason they failed to thrive was because they developed a very bad reputation security-wise; it was difficult to get functionality and security reconciled. – Ed Staub Mar 11 '14 at 14:10