我想知道如何确定.NET托pipe服务提供商可以安全地给予他们的客户完全信任？
这是不是打开了所有与该公司有关的潜在安全问题？ 还是有办法可以安全地限制每个客户，尽pipe给予他们的“他们”的空间，而不给他们的能力，打倒系统或间谍的其他客户的完全信任？
在某些方面，它可能会从一个应用程序中打开出现问题的可能性，从而影响其他应用程序。
但是，完全信任在默认情况下已经非常安全，特别是来自外部的攻击。 完全信任场景中的最大风险来自合法用户，他们可能会上传和运行一些愚蠢的代码。 但是，在整体实践中这是一个小的风险，这就是为什么你看到托pipe完全信任。
主机提供商还做了一些事情，除了进一步减less一个错误的用户的白痴的影响。 大多数提供商做了一些调整，以“完全信任”的默认值，以消除asp.net解决scheme实际上不需要的function。 他们也倾向于在服务器上的不同应用程序池中运行每个用户的帐户。
此外，还有一些问题，导致完全信任的默认中等信任设置很难实现与许多asp.net应用程序。 微软对代码访问安全性和信任级别在asp.net 4.0中的工作方式做了一些改变，以解决这些问题。 我还没有深入到最后的细节，但你可以在这些链接find他们的一些信息：
.NET Framework 4中的安全更改
ASP.NET 4应用程序中的代码访问安全性
.net框架的“信任”问题与保护服务器无关。 至less不是直接的。
托pipe服务提供商（应该）通过向托pipe用户授予有限的用户权限来保护他们的服务器。 这些权利是在操作系统级授予的。 用户正在使用的虚拟机或语言不相关。 从大多数语言你可以访问win32 api或posix api，尽可能多的损害，你的安全许可将允许你。
.net框架的“信任”模式所涵盖的场景与浏览器中托pipe的JavaScriptparsing器所提供的场景并没有多大区别。 考虑以下几点：你正在写一些游戏服务器。 而且你也不会允许第三方为你的游戏写扩展名。 您将在您的服务器上运行由第三方提供的dll。 你想让他们打电话给你的API。 但你肯定不想让他们直接嗅探你的磁盘或数据库。 在这种情况下，操作系统的安全性不会帮助你，因为这些DLL会在你的进程中运行你的凭证。 所以你加载这些DLL的restiricted信任。 .net框架将确保他们不会调用任何危险的API。