views:

301

answers:

3

It's not difficult for me to save code to temp folder, use csc.exe to compile it and load the assembly dinamically, but how can I execute the code with limited permissions?

For example, how can I prohibit the code from...

  • creating new threads.
  • doing any I/O operations.
  • granting higher permissions.
  • gathering information of the system.
  • executing dead cycle (well, it's not about security).
  • use too much memory.
  • any other dangrous things...

Any information(blog/article/paper/manual...) is welcomed.

+3  A: 

You probably need to load the assembly in a different AppDomain, which you create giving it the permissions you wish it to have. Generally, assemblies loaded into the default AppDomain will have the permissions delegated to that AppDomain. By creating another AppDomain, you will have complete control over what permissions that AppDomain is given, which propagates down to the assemblies loaded into it.

One caveat, however, is that calls to code loaded into another AppDomain will need to be marshaled, which will affect performance somewhat.

The following articles should help get you started:

http://blogs.msdn.com/shawnfa/archive/2004/10/25/247379.aspx

http://blogs.msdn.com/shawnfa/archive/2004/10/22/246549.aspx

jrista
A: 

There are two ways of looking at this; the first is via an AppDomain with separate trust, which jrista has given a good answer about. The second is: don't compile arbitrary/user code ;-p Depending on the scenario, you may be able to construct a DSL with access to only the functionality you are happy to expose, and compile that. I've used this approach successfully a number of times. This creates a very controlled sandbox - the only thing to watch is things like infinite loops, but even that is fixable if you really need.

So I guess the real question is: does the input have to be C#? Or is that just a convenience?

Marc Gravell
A: 

IMO, the start is create a guest user account to run the process under. Then follow additional steps.

leppie
A different user account won't prevent (from the question) thread creation, memory over-use, IO (from public areas), system-info gathering (of non-priveleged data), etc...
Marc Gravell
Well it covers the 'other dangerous things' part :)
leppie