views:

60

answers:

1

I have a web application that can load plugins through reflection. It currently uses Assembly.LoadFrom() and Activator.CreateInstance() to get this done. Right now plugins are loaded into the same AppDomain and have access to anything in my app and anything my app could access.

What I'm looking for is a way to limit what classes and methods the plugin can access for security purposes. I want to have all of my classes and methods throw an exception when called unless they are whitelisted. I'd be whitelisting basically all the functions in an API class and a few data transfer objects.

I also don't want the plugin to be able to access the filesystem or the database on it's own. I think I can do that with trust levels in a separate AppDomain though.

Does anyone out there have any good ideas or resources? Is this something that could be done with Code Access Security or the new Security-Transparent Code features in .net 4?

+2  A: 

Using a separate AppDomain is the right approach if you want to apply general access restrictions. As for restricting access to your app-specific logic, just don't give out instances of your 'app internal' service objects to the plugin objects. Also, any reference type objects that are not MarshalByRef won't cross the AppDomain boundaries, so these objects are safe from access, even if there are exposed methods that would try to return them.

Dan Bryant
This sounds promising, however what is stopping the plugin from calling into static methods or creating new instances of objects? I'm a little concerned the plugin might be able to get at information that it shouldn't see like connection strings.
David Hogue
It's non-trivial to create a design that allows secure integration of extensions. You can't prevent instantiation of objects or access to static members, but you do have full control over access to any actual instances in your original AppDomain. The plugin will only get instances you explicitly Marshal. The key is that a plugin instantiating your classes should not allow your application state to be mutated, since none of them can ever get a reference to your real application state. Other indirect side effects (like file system or OS access) are controlled via AppDomain security settings.
Dan Bryant