.NET Framework 4.x中的插件系统安全性(无CAS)

Question

我想要实现的是一个具有以下功能的插件系统:

• 从我可能不信任的来源(开发人员)加载外部插件,但是安装插件的最终用户信任
• 授予特定范围内的每插件权限; 例如,一个插件可能具有从特定位置读取文件的许可,而其他插件可能被允许连接到特定的网站位置
• 每个插件权限的一个特例:与另一个对象交互,很可能作为接口实例提供,而不访问任何非公共成员(甚至没有偷偷摸摸的反射技术)
• 在插件代码可以造成任何伤害之前,防止最终用户不同意的操作,例如访问非公共成员或操作文件系统

在我的搜索过程中,我发现大多数SO解决方案涉及代码访问安全性,据我所知,从.NET 4.x开始已经过时了.我还在MSDN页面上阅读了一些关于新安全模型的内容,看来有必要公开受保护资源的库代码 ; 但是,我找不到任何显示如何应用此类代码的示例.我的猜测是,它将涉及创建单独的AppDomains并可能使用Principal权限,但这就是我所知道的.

另外,我还发现只提到强烈命名的集会,但我不相信这就足够了.如果我没有弄错的话,强大的命名优势之一就是插件开发人员可以通过使用自己的私钥对组件哈希进行签名来证明自己的身份,而其他人可以使用知名且可信的公钥进行检查.然而,仅此一点似乎太不灵活,因为它要么要求开发人员亲自决定应该信任哪些代码,要么只信任任何学会签署其程序集的人.

我将非常感谢使用最新安全模型的安全管理代码的一个很好的例子.我目前的想法:

• 用于暴露潜在敏感操作(例如A和B)的服务接口
• 服务的虚拟实现,重点是防止未经授权执行这些操作
• 来自不同程序集的两个插件,一个具有执行操作A的权限,另一个具有操作B的权限
• 设置服务的应用程序,使用插件加载程序集并尝试对每个程序执行操作,以便阻止未经授权的操作并正确执行授权操作
• 当在应用程序中运行时,它们本身的插件都不应该能够访问常规敏感API,例如文件I/O或网络,但是应该可以通过服务来完成
• 所有这些都尽可能地遵循这些建议(与2010年的SO问题的基于CAS的解决方案相反)

当然,如果它以更好的方式实现目标,欢迎您建议另一种架构.

Answer 1

你要问的是多层次的难点.

我见过的最近的事情是一个名为Terrarium的长期被遗忘的Microsoft项目,你使用.net语言编写一个生物,构建它,然后将包含你的生物的程序集提交到用.NET编写的terrarium服务器上. 1.0.对于MS开发人员来说,创建一个任何用户都可以运行代码但是安全并且玩得很好的环境是一个挑战.他们创建了一个禁止某些类型用于装配的工具.它被称为AsmCheck.

我曾尝试使用app域实现相同的功能,但没有取得多大成功.

我不时会想到实现这一任务的最佳方法是什么.有可能,Android和iOS就是这样,但它需要我编写完整的操作系统或框架.

我打算创建一个AppDomain并将我的插件加载器加载到这个域.然后,Loader通过劫持程序集加载程序加载插件程序集和它尝试加载的所有程序集.加载程序集时,它使用AsmCheck.vNext检查它是否有阴影.对于它加载的每个程序集,它使用IoC容器(如此)来限制对框架的访问.

通过使用我的插件注册表检查强名称或检查代码签名的证书,我可以验证程序集.

在您看到Confuser或其后续ConfuserEx之前,一切似乎都很好.它通过将方法转换为自我初始化静态委托来创建代理类型来访问方法,静态委托不是通过名称而是通过引用ID引用方法.现在,我怎么可能分析和/或限制对此的访问.

或者您可以完全阻止System.IO命名空间并为您提供自己的IO库,但是如何限制一个使用PInvoke并调用GetProcAddress以便它可以访问ReadFile,WriteFile等...

只是太多的情况要处理,这只是冰山一角.如果你必须限制插件来做东西,你必须编写自己的框架或提供像lua这样的脚本语言.

您可以尝试App Containerization.每个插件都加载到一个特殊的容器中,并与您的应用程序进行通信,以执行需要权限的任务.除此之外,在容器think container中运行的代码是整个计算机.

有一天,我希望看到有人以简单有效的方式解决这个问题.

PS:我的回答不是答案.这是一个答案,因为它不适合评论.