Is it possible to host the .Net DLR in an "idiot-proof" sandbox?

Question

I would like to host the Dynamic Language Runtime (DLR) in such a way that users who run arbitrary scripts in it cannot bring the process down?

The DLR hosting spec describes how to host the DLR in a separate ApplicationDomain. This allows to tear down and unload a script runtime and to restrict certain operations through CAS (e.g. I can restrict file system access or disallow use of reflection).

But are there also ways to for example:

• restrict the maximum amount of memory used by a script?
• restrict the number of threads created by a script?
• detect deadlocked scripts?

I think such fine grained control could be possible using the unmanaged .net hosting API that was developed for SQL server. Is this the direction to go? Are there open source projects for this kind of general .net sandboxing?

Here are a few potentially useful references that I found:

• Discover Techniques for Safely Hosting Untrusted Add-Ins with the .NET Framework 2.0
• Host protection thread on DLR discussion list
• Using Host Protection (.Net security blog)

Faintheart

Answer 1

Have a look at Terrarium -- it's a game where you build your own autonomous critters in a .NET language, and they're teleported to other networked computers along with the assemblies that they're described in. The goal is to have your critter take over the entire ecosystem, either by killing everything else or by strategically managing food resources.

As I recall, any critter that spends more than 0.n seconds "thinking" or n kb of memory gets deleted.

Cheesy

Very interesting project. :-) I just downloaded the source and did a very quick review: They use a native code C++ project called "asmcheck" to literally disassemble a 'creature assembly' and check which .net types it is using/accessing. They use a hard-coded black list for "banned types" like System.Threading.Thread. Although this is a quite interesting solution I think this approach cannot be directly applied to the DLR. – Faintheart

Really? That's sort of surprising. I always thought they use CAS: en.wikipedia.org/wiki/Code_Access_Security – Cheesy