执行不受信任的代码

Question

我正在构建一个使用插件的 C# 应用程序。应用程序必须向用户保证插件不会在用户计算机上为所欲为，并且拥有比应用程序本身更少的权限（例如，应用程序可以访问自己的日志文件，而插件则不能） 。

我考虑了三种选择。

1. 使用 System.AddIn。我首先尝试了这个替代方案，因为它看起来非常强大，但每次我想修改某些内容时都需要在七个不同的项目中修改相同的代码七次，我真的很失望。此外，即使是一个简单的 Hello World 应用程序，也有大量问题需要解决。

2. 使用System.Activator.CreateInstance（程序集名称，类型名称）。这是我在应用程序的先前版本中使用的。我再也不能使用它，因为它没有提供限制权限的方法。

3. 使用 System.Activator.CreateInstance(AppDomain 域，[...])。这就是我现在正在尝试实现的，但似乎唯一的方法是通过 ObjectHandle，这需要对每个使用的类进行序列化。尽管插件包含不可序列化的 WPF UserControls。

那么有没有办法创建包含 UserControls 或其他不可序列化对象的插件并使用自定义 PermissionSet 执行这些插件？

Answer 1

您可以做的一件事是将当前 AppDomain 的策略级别设置为受限权限集，并添加证据标记以根据强名称或位置进行限制。最简单的可能是要求插件位于特定目录中并给它们一个限制性策略。

例如，

public static void SetRestrictedLevel(Uri path)
{
    PolicyLevel appDomainLevel = PolicyLevel.CreateAppDomainLevel();            

    // Create simple root policy normally with FullTrust
    PolicyStatement fullPolicy = new PolicyStatement(appDomainLevel.GetNamedPermissionSet("FullTrust"));
    UnionCodeGroup policyRoot = new UnionCodeGroup(new AllMembershipCondition(), fullPolicy);

    // Build restrictred permission set 
    PermissionSet permSet = new PermissionSet(PermissionState.None);            
    permSet.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));            
    PolicyStatement permissions = new PolicyStatement(permSet, PolicyStatementAttribute.Exclusive);
    policyRoot.AddChild(new UnionCodeGroup(new UrlMembershipCondition(path.ToString()), permissions));            

    appDomainLevel.RootCodeGroup = policyRoot;

    AppDomain.CurrentDomain.SetAppDomainPolicy(appDomainLevel);
}

static void RunPlugin()
{
    try
    {                
        SetRestrictedLevel(new Uri("file:///c:/plugins/*"));                

        Assembly a = Assembly.LoadFrom("file:///c:/plugins/ClassLibrary.dll");
        Type t = a.GetType("ClassLibrary.TestClass");
        /* Will throw an exception */                
        t.InvokeMember("DoSomething", BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Static,
                null, null, null);
     }
     catch (Exception e)
     {
         Console.WriteLine(e.ToString());
     }
}

当然，这没有经过严格的测试，而且 CAS 策略非常复杂，因此始终存在此代码可能允许某些内容绕过策略的风险，YMMV :)