Im currently adding a interface to my application so other people can extend it with plugins. My application is used by MMO gamers and i will not have any control over the plugins ( In that anyone will be allowed to make them ) and i was hoping i could have some degree of control over the code in the plugins.
What im afraid of is someone making a plugin that either contains bad code that starts writing to folders outside "allowed" folders or does this by design. Since this will be run by a MMO gamers some sort of keylogger would be very bad.
So im hoping there is a way for me to:
Force the plugin to run inside a sandbox where it does not have direct access to filesystem,windows or network. In effect forcing them to use the API i provide for those actions.
I was thinking it might be posible to inspect the plugin dll hoping it contained a list of what namespaces it uses, and simply not load plugins that contained "bad" namespaces.
My plugin interface is based on this great codeproject artice , i did try to search for some information on this. But i was unable to refine my search to a point where it returned something usefull, if it mathers my skill level is C# and some cross platform c++.
It would be possible to inspect the assembly for certain things before you load it. Prior to executing code or constructing a type within the assembly, you could run through the entire set of assembly types and references using reflection, and search for "invalid" references. However, this is not going to be very effective, as you're always searching for things that are bad - when really, you need to define the operations that are good, instead, and only allow those.
The only way to cleanly enforce a different security policy for plugin is to load the plugin into a different AppDomain.
By loading the plugin in it's own AppDomain, you can enforce different security policies upon its code (basically run it within a sand box). You can provide interfaces or classes that are passed into the plugin in order to give it access to functionality beyond those in the plugin itself.
Related
I'm building a project that will support loading in external, managed DLLs, essentially as a modding system. However due to security reasons I'd like to restrict (as far as possible) what those external DLLs can access and do because they won't be made by myself.
My current plan was to simply blanket ban every assembly besides a select whitelist which I can add to upon request, however my main issue is the System.dll. It's probably the most important one to restrict access to due to the obvious reason that it can access System, however it also has vital namespaces like System.Collections, so it needs to be useable.
Is there a way to check specifically what assemblies and namespaces a loaded DLL is utilising or am I going about this the wrong way?
Currently I'm working on a .NET hobby project that involves a complex system of objects which work in combination with eachother. However, I encountered a little problem, I am unable to find a mechanism in .NET to support replacing code at runtime, and be able to dispose of the old code, loaded previously. This means replacing a module/object dynamically and almost instantly displaying the changes to the user, for example, when he restarts a procedure, but not the whole program.
I have already taken into account the possibility of having separate AppDomain for each session and loading the necessary assemblies into it but this seems a little bit too expensive. I should also mention that every session benefits from a common base of assemblies, for instance, to connect to a database, so this means loading those classes into every single session. Marshalling data back and forth from the separate AppDomain also represents an additional overhead (could be used when data is sent to the client application through the network, code for this contained in the main AppDomain, which manages the sessions).
Is there a framework or way of replacing/unloading particular parts of code? How is it done in real-world applications? Can there be a workaround? Or have I picked the wrong set of tools?
You need some kind of plugin system with well defined interfaces. Then you load at runtime binaries (your plugin *.dll) and create objects from it and then execute methods on it.
When you create a system where objects from your plugins must be created through your IPluginManager you have no problem with replacing code at runtime. :)
Or
You have something like a folder with *.cs files which will on demand compiled (in memory) and create the objects you want to use from them and call the methods on them.
Which is basically the same like above, without compiling at run time.
From there you can make further improvements.
EDIT:
Like you wrote the only problem without using AppDomain is that once loaded assemblies can't be unloaded. But that's not really a problem.
I don't think you need separate AppDomains: you can dynamically load assemblies within the current AppDomain. And each assembly should probably implement some defined interfaces (depending on your usage). You could use the FileSystemWatcher class, for example, to load/unload assemblies as needed.
See http://msdn.microsoft.com/en-us/library/25y1ya39(v=vs.110).aspx
You can have a look at MEF. It stands for: Managed Extensibility Framework .
Here's another article about it MEF on codeproject.
It is used to load dll's in runtime by composing them. This is what is usually used for plugins or anything else you kinda drop into a folder and expect it to run .
Here's a link to some more tutorials as well: Where can I learn about MEF?
Yes, you're right, it is not possible to simply unload an assembly (only AppDomains). But I think one of the features of ASP.Net vNext is the ability to have just in-memory assemblies and when you simply alter the source code on the drive it gets automatically compiled and loaded. Therefor a mechanism must exist to unload the previous version.
I think they are doing that by simply creating a AppDomain where all assemblies are loaded into again to avoid any cross domain communication. But i don't really know and maybe if you would dig more into the mechanism on how they do this stuff in ASP.NET you maybe find a good solution. More informations about the hot topics from vNext you can maybe also find at Scotts Blog.
Well, I've found 2 solutions that work for me, which I would like to share. The first one is to use CollectibleAssembly and define the types. This is certainly a bit tricky, and a number of restrictions are imposed on this type of dynamic assembies.
The other option is to use a scripting language like IronPython or IronRuby. Also a great feature of the new Roslyn compiler is that it also provides scripting APIs, not previously available in the .NET framework. What's more, the Roslyn scripting languages tend to look very much like their full-blown equivalents (C# or VB). And I've also found a tiny example of its capabilites.
I need to be able to allow mods/patches to a very simple game. Essentially I need to allow a folder full of DLL files to be loaded and have their functions override those of the original application.
I know the basics of a hook system where a line of code can be placed throughout the application source to "bring in" code from outside variables and the likes.
I have tried to search for this, however as I am not sure of the terminology I have ended up sifting through about 30 sites and coming back to gaming websites with instructions on how to specifically mods their games. This information was helpful but I need a little assistance
My question is: Is there an common term for what I am trying to achieve that will assist me in google searches?
You should probably look for .NET plug-in/add-in framework. .NET Fx since 3.5 contains its own add-in framework but that may be overkill for your requirement. As such what you want to achieve is quite simple in .NET - here's the broad outline of it:
Define various interfaces (hooks) that need to be implemented by third party. Package them in a separate dll with documentation.
Create a configuration item (a config entry) that will accept the fully qualified type name implementing the requisite interface.
In your program, load the type using the above config entry. You can use reflection for that (see Activator.CreateInstance). Cast the object to interface and use it.
Third party is supposed to provide implementation of these interfaces and place the dll under application folder. And modify config entry to put the type name.
Not sure, but given .NET context, MEF (Managed Extensible Framework) or System.AddIns could work.
I have a .NET 2.0 application. What I want to do is create a plugin that has access to the main application in some way.
My reason is that I want to be able to add things like buttons and menu items to a form dynamically instead of having a menu item called "Plugins" that I update. This is so that I can add things to the application GUI without releasing the entire application again.
Right now I can think of two ways. One, I can create the plugin in such a way that it always expects a reference to the entire application, all forms included. I can give it access to whatever items I chose in the forms and it can add controls or whatever at will. This makes me a little uneasy, but if this is acceptable let me know.
The other way I can think of is to have some sort of Interface for each form in the main app such that I can use that interface to access the current forms in the app. I am not sure how to implement this, though.
All help, suggestions, website references and comments are appreciated.
Partly this comes down to who will write your plug-ins, do you trust them, and what happens to the user's experience or data when a plug-in goes bad?
Fiddler http://www.fiddler2.com/fiddler2/ is a Web Debugging Proxy that has a plug-in model very much like your first choice - expose everything to the plug-in writer and hope they don't screw up. This makes writing extensions to Fiddler very simple, but it does mean you need to be careful.
If you're unhappy about this approach I would suggest you take a close look at 2 .NET technologies that might help.
The first is the System.AddIn namespace http://msdn.microsoft.com/en-us/library/gg145020.aspx. The types in this namespace are designed to help you create applications that support AddIns.
The second is MEF http://mef.codeplex.com/. The Managed Extensibility Framework is a very powerful API for describing an applications requirements, and allows you to build highly extensible applications.
With regard to MEF and WinForms check out this SO question:
Winforms with MEF
The second approach would be preferible, you could create an interface IApplication with all of the modifyable / pluggable parts of your appilcations and require that all plugins implement and IModifyApp interface with some method like IModifyApp.Modify(IApplication) that takes an instance of the IApplication and returns a modified instance for the application to process.
You should also check out MEF The Microsoft managed extensibility framework.
What I have done before for this kinda scenario is used AppDomain. Which is like a process inside your main process. You can load and unload assemblies in the AppDomain w.o having to stop the main process and as long as your main process knows about interfaces loaded from the "updates" dll inside the AppDomain, it can consume it no problem. If not, then there are always reflections :)
You may want to give a look to something like CAB/Prism to address your needs. A lot of the UI-y-ness (technical term) is built in to that through a series of abstractions.
http://compositewpf.codeplex.com/
What recommendations can you give for a system which must do the following:
Load Plugins (and eventually execute them) but have 2 methods of loading these plugins:
Load only authorized plugins
(developed by the owner of the
software)
Load all plugins
And we need to be reasonably secure that the authorized plugins are the real deal (unmodified). However all plugins must be in seperate assemblies. I've been looking at using strong named assemblies for the plugins, with the public key stored in the loader application, but to me this seems too easy to modify the public key within the loader application (if the user was so inclined) regardless of any obfuscation of the loader application. Any more secure ideas?
Basically, if you're putting your code on someone else's machine, there's no absolute guarantee of security.
You can look at all kinds of security tricks, but in the end, the code is on their machine so it's out of your control.
How much do you stand to lose if the end user loads an unauthorised plugin?
How much do you stand to lose if the end user loads an unauthorised plugin?
Admittedly this won't happen often, but when/if it does happen we lose a lot and I although I understand we will produce nothing 100% secure, I want to make it enough of a hindrance to put people off doing it.
The annoying thing about going with a simple dynamic loading with full strong name, is that all it takes is a simple string literal change within the loader app to load any other assembly even though the plugins are signed.
you can broaden your question : "how can I protect my .net assemblies from reverse engineering ?"
the answer is - you can not. for those who havent seen it yet, just look up "reflector", and run it on some naive exe.
(by the way, this is always the answer for code that is out of your hands, as long as you do not have en/decryption hardware sent with it),
obfuscating tries to make the reverse engineering to be harder (cost more money) than development, and for some types of algorithems it succeeds.
Sign the assemblies.
Strong-name signing, or strong-naming,
gives a software component a globally
unique identity that cannot be spoofed
by someone else. Strong names are used
to guarantee that component
dependencies and configuration
statements map to exactly the right
component and component version.
http://msdn.microsoft.com/en-us/library/h4fa028b(VS.80).aspx