Reputation: 13
I'm allowing users of my application to run snippets of C# to be able to directly manipulate certain objects in my assemblies without me having to write a big scripting interface layer to explicitly expose everything.
This code will be injected into a dynamically compiled assembly, so I can control the assembly itself, but I need to stop the code accessing my private methods using reflection.
I tried calling securityPermissionObject.Deny() just before running the code, but this blocks methods on my objects from using reflection (which some do) when they are called by the user's code.
Is there a way to restrict the permissions only on the suspicious assembly without affecting the public methods it calls on my trusted assemblies?
Upvotes: 1
Views: 950
Reputation: 239814
(An old question, not sure whether you still need an answer)
When calls are coming back into your public methods, then the first thing you need to do is carefully sanitize the parameters, and reject any bad calls. After that, you can add a call to Assert for RelectionPermission. This basically allows any code you call which requires reflection to be satisfied, and not see the Deny higher up in the call stack.
Upvotes: 0
Reputation: 12906
Try to create a new appdomain. And use it as a sandbox. Within this sandbox you can load your assembly in.
Here is an example.
Of course because you now have two appdomains it complicates communictiaon a bit. You might consider a Webservice through a pipe or other communication mechanisms.
Here is an article of how two appdomains can communicate.
Upvotes: 1