title: Embedded IronPython Security
body: <p>I am embedding IronPython into my game engine, where you can attach scripts to objects. I don't want scripts to be able to just access the CLR whenever they want, because then they could pretty much do anything.</p>
  
  <p>Having random scripts, especially if downloaded from the internet, being able to open internet connections, access the users HDD, or modify the internal game state is a very bad thing.</p>
  
  <p>Normally people would just suggest, "Use a seperate AppDomain". However, unless I am severely mistaken, cross-AppDomains are slow. Very slow. Too slow for a game engine. So I am looking at alternatives.</p>
  
  <p>I thought about compiling a custom version of IronPython that stops you from being able import clr or any namespace, thus limiting it to the standard library.</p>
  
  <p>The option I would rather go with goes along the following lines:</p>
  
  <pre><code>__builtins__.__import__ = None #Stops imports working
  reload = None #Stops reloading working (specifically stops them reloading builtins
            #giving back an unbroken __import___!
  </code></pre>
  
  <p>I read this in another stack overflow post.
  Assume that instead of setting __ builtins_<em>.</em>_ import__ to none, I instead set it to a custom function that lets you load the standard API.</p>
  
  <p>The question is, using the method outlined above, would there be any way for a script to be able to be able to get access to the clr module, the .net BCL, or anything else that could potentially do bad things? Or should I go with modifying the source? A third option?</p>