Limit third-party C # features

Question

There is a (modular) game application - the arena, it implements an abstract class (or interface) for the player. Players (game AI) inherit from the specified class and develop third-party developers and provide a compiled dll. Is there any way to limit the capabilities of this third-party dll? Well, for example, protect yourself from "FORMAT C:" or from sending data over the network, reading from a disk, etc. Even if this class falls in this case, then the player simply counts as a technical loss.

What a day I fight, but at least kill, I can’t understand how to make it work. How to make all third-party players work in the sandbox? Now there is something like this code:

static class PlayersHost { static public List<IPlayer> Players; static public void LoadPlayers() { Players = new List<IPlayer>(); var files = Directory.EnumerateFiles(Path.Combine(Environment.CurrentDirectory, "Players"), "*.dll"); foreach (var file in files) { try { var asm = Assembly.LoadFrom(file); var types = asm.GetTypes(); foreach (var type in types) { try { IPlayer player = (IPlayer)Activator.CreateInstance(type); players.Add(player); } catch { } } } catch { } } } }

Then I just load all the players when the application starts:

 PlayersHost.LoadPlayers();

and use the resulting collection, for example:

 var player = PlayersHost.Players[0]; try { player.PrepareToPlay(); } catch { }

Need a solution using AppDomain

new SecurityPermission(SecurityPermissionFlag.Execution).PermitOnly()
What do you, the person who appointed the award, would like to hear in response to this question?
Ready-made solution using AppDomain, preferably at the lowest cost and that the existing code is not badly affected.

morincer morincer 521 3 silver marks 6 bronze marks · Accepted Answer · 2016-10-15T07:52:26

To isolate partially trusted code, .NET provides a mechanism to restrict access within the AppDomain - this is called Sandbox (running in the sandbox).

 AppDomain.CreateDomain( string friendlyName, Evidence securityInfo, AppDomainSetup info, PermissionSet grantSet, params StrongName[] fullTrustAssemblies);

Information on how to use it, as well as a number of additional considerations and nuances are described in detail in this article on MSDN: https://msdn.microsoft.com/ru-ru/library/bb763046(v=vs.110).aspx

Well, by the way, domains will also be more than useful for dynamic loading and unloading of these DLLs.
I just think it's worth adding the answer: the classes that should be used in a separate domain from the main one should inherit from MarshalByRefObject

Answer 2 · 2016-10-15T10:24:35

An alternative, higher-level solution would be to use System.AddIn . This framework is more complex than using the AppDomain , but it provides more features. In particular, it allows you to automatically find downloaded add-ins, and download them according to your wishes.

in the current AppDomain
in a separate, special AppDomain for components you don’t trust
each component in a separate AppDomain
in a separate external process
each component in a separate AppDomain shared external process.

In this case, the interaction protocol remains the same. At the same time, objects that cross the border between the main code and add-ins should be serializable.

Unfortunately, a full-fledged example does not fit into the response format, but a good example is in the documentation:

MAF and MEF are two sides of the same coin, MEF is lighter, but less flexible, MAF is flexible, functional and terribly cumbersome.
@rdorn: MEF in itself seems to be only for trusted plug-ins, it seems?
And if you need dynamic loading and unloading plug-ins, then only in a separate domain to load.

Limit third-party C # features

2 answers 2

More articles: