none
Running Untrusted Code with ScriptEngine

    Question

  • What is the recommended way to run code with ScriptEngine in Partial Trust?

    I suppose the scripting API will be heavily used to run untrusted code, so it would be nice to specify the permissions easily.

    vendredi 21 octobre 2011 23:40

Réponses

  • ScriptEngine executes the code in the same AppDomain as it compiles it in. There is no support for remoting today. Are you familiar with DLR hosting API? It supports remote execution. You pass it an AppDomain to run code in (a sandbox). It's up to you how you set the AppDomain up, what permissions you assign it. So that migth be one approach we might consider.

    Another approach migth be to apply a visitor on the syntax tree that makes sure that the script is only using methods and types taht you white-list.

    Neither of these are available in the CTP. BTW, the compiler itself today requires full trust (as in running unverifiable code and p/invoking).

    samedi 22 octobre 2011 00:34

Toutes les réponses

  • ScriptEngine executes the code in the same AppDomain as it compiles it in. There is no support for remoting today. Are you familiar with DLR hosting API? It supports remote execution. You pass it an AppDomain to run code in (a sandbox). It's up to you how you set the AppDomain up, what permissions you assign it. So that migth be one approach we might consider.

    Another approach migth be to apply a visitor on the syntax tree that makes sure that the script is only using methods and types taht you white-list.

    Neither of these are available in the CTP. BTW, the compiler itself today requires full trust (as in running unverifiable code and p/invoking).

    samedi 22 octobre 2011 00:34
  • Just a bit of additional related feedback for the scripting API:

    It would be a huge benefit for users trying to use the scripting API for .Net application extensibility (i.e., exposing specific scriptable customization points in your application) if it were easier to deal with trust and unload (basically what we are using AppDomain for currently). If the scripting API had a convenient way to wrap this up for you it would be a huge advantage (in my opinion at least).

    Example use cases would be companies developing application frameworks, customizable products, etc. One example is a hosted solution that allows many customers to customize their 'instance' of the product. A lot of time would be spent on the plumbing around the AppDomains and assembly management. The scripting API would provide a lot of great ways to get the script code in (i.e., expose a simple script window instead of uploading assembly plugins, etc.), but the execution context issues (security, and loading changed script) are still the same.

    I image that most applications that want to provide scriptable customization points would need a way to a) run script in a secure sandbox, and b) unload/reload script in an efficient way (avoid memory leaks) (imagine users of such apps writing customization script, testing it, changing it, testing it, etc.).


    Anthony Allison

    mardi 27 mars 2012 21:27
  • Hi, Anthony.  Thanks for the follow up.  We definitely have this sort of issue on our radar, but we haven't had time to dig into this part of scripting yet.  It is highly likely, given our current thinking, that we'd do something like the DLR Hosting API for remoting to appdomains and use .NET's mechanism for sandboxing, unloading, etc.  We also are currently thinking of providing some lighterweight controls such as white/black lists of APIs that could be set per engine.  Anyway, it will be a while before we dig into these sorts of host controls since we have some other basic cancellation and execution/compilation work to do first.

    Cheers,

    Bill

    mercredi 28 mars 2012 15:34
  • Hey,
    i have an idea, how to provide untrusted scripting on an central internet services, without using a sandbox, scripting, other appdomain. Simply analyze it with NRefactory5, test all used types and members(in the types) via resolving, and when they are outside the compiled assembly and are not in the white-list(black lists are too unsecure), the user script will be completly rejected. With this way, only two things can be dangerous: Wasting CPU cycles(but solveable with priority/and thread kill meachanism) and running into an outofmemory exception(but on x64, this is quietly hard, and when a script can run only for 10 seconds, this should be impossible, too).

    But the most problem from all is definitly, to breakout of the sandbox and accessing server objects/other user objects. I think my way could work very well, do you see any problems? I would offer this in my internet service. In the moment, i have an own written scripting engine(own language, running inprocess, same appdomain, white list, extremly fast), but it's not so powerfull than c# ;)

    Greetings,
    Sebastian

    vendredi 27 juillet 2012 21:40