Limiting What Code Can Do/Access?

I'm compiling code as an assembly object in memory, then running a void function called ScriptMain() in that code on a new thread. Without compiling the code to a file and loading it into an AppDomain, how could I apply security and limits to the code? Or do I apply some sort of limiting security to the thread on which it executes? I want my users to be able to write scripts for only my application, and not access the entire .NET framework.

Someone please give me some insight on this, I'll post the code if necessary, just too lazy to go get it off my laptop via flash drive right now.

Create a class that uses your own Scanner, Tokenizer and Parser. Read the code and only parse the stuff you want to allow for your application. This way you will have your own syntax with absolutely no restrictions on the control you'll have on the language. Then, manually map the statements to the IL using CodeDom. This is tough, I know. But this is the best method if you want to limit the functionality. If you don't want to do that, you can limit the functionality to a certain extent by granting security permissions for your assembly. For Example, you can access the classes in Security.Permissions to grant desired permissions: System.Security.Permissions.SecurityPermission

Since I don't think I'm quite to the level of writing my own language interpreter, I'll try out security permissions.

Thanks man.

Well, if you're going for an interpreter, you don't need to use IL instructions. This means you will not get an executable but a true interpreter. But it's really up to you to decide.
Here's a simple interpreter I wrote last year. Should give you some food for thought:

http://www.mpgh.net/forum/33-visual-...-language.html

Simply put, it's not possible. You just can't stop an application using the .NET framework if you're letting it compile into that. You can, however, (programatically) disassemble the code, analysing all calls, seeing if its to the .NET framework and not allowing the application to run or similar action. Alternatively, you could possibly patch the target method and make it throw an exception. I haven't that much experience with detouring .NET applications though, so I'm not sure of the implications this would have (are the libraries shared in the same app domain, module or process etc).

It'd be easier to use Javascript or something. Syntax is similar. Libraries and wqhitelisted methods can be exposed and so on.

Why don't you just sign all the modules you want your product to work with? Its utterly inefficient to reinvent a parser\tokenizer & interpreter for the sole purpose of imposing some security systems. Also, you can expect a serious down-pour in performance if you do. Reinventing the wheel is usually frowned upon so if you are going to implement a scripting engine, don't write a new one with new syntax unless the others are not appropriate (and they are.)

This seems to be some sort of plugin system as far as I can see, so just sign all the scripts you want the users to use and then decrypt them with a public key.

Originally Posted by Hassan

This would take about 89% of the development time for a small security improvement and poor optimization with some rather difficult to maintain code.

Limiting What Code Can Do/Access?

Post a Reply

Similar Threads

Tags for this Thread