7. 代码访问安全性
7.1 什么是代码访问安全性 (CAS)?
CAS 是 .NET 安全性模型的一部分,它确定一段代码是否允许被运行,以及当它运行是可以使用什么资源。例如,CAS 可以防止一个 .NET 的 Web applet 将你的硬盘格式化。
 
7.2 CAS 如何起作用?
CAS 安全策略设计两个关键概念—代码组和权限。每个 .NET 元件是特定 代码组的成员,并且每个代码组被授予由有名权限集所指定的权限。
例如,使用默认的安全策略时,一个从 Web 站点的控件属于“Zone - Internet”代码组,它保持由有名权限集“Internet”所定义的权限。(自然,有名权限集“Internet”表示一组受到严格限制的权限。)
 
7.3 谁定义 CAS 代码组?
Microsoft 定义了一些默认代码组,但你可以改变这些甚至创建你自己的代码组。要想看到你的系统中定义的代码组,可以从命令横行运行“caspol -lg”命令。再我的系统里它看起来像这些:
Level = Machine

Code Groups:

1.  All code: Nothing
   1.1.  Zone - MyComputer: FullTrust
      1.1.1.  Honor SkipVerification requests: SkipVerification
   1.2.  Zone - Intranet: LocalIntranet
   1.3.  Zone - Internet: Internet
   1.4.  Zone - Untrusted: Nothing
   1.5.  Zone - Trusted: Internet
   1.6.  StrongName - 0024000004800000940000000602000000240000525341310004000003
000000CFCB3291AA715FE99D40D49040336F9056D7886FED46775BC7BB5430BA4444FEF8348EBD06
F962F39776AE4DC3B7B04A7FE6F49F25F740423EBF2C0B89698D8D08AC48D69CED0FC8F83B465E08
07AC11EC1DCC7D054E807A43336DDE408A5393A48556123272CEEEE72F1660B71927D38561AABF5C
AC1DF1734633C602F8F2D5: Everything
注意代码组的层次—顶层 (All code) 是最通用的,它随后分为几个组,每个还可以再分。同时注意,和一般的想象不同,子组可以被赋予比它的上级更宽的权限集。
 
7.4 如何定义自己的代码组?
使用 caspol。例如,假定你信任来自 www.mydomain.com 的代码,并且希望它对你的系统拥有完全的访问权,但是希望对其它 Internet 站点保持默认的限制。要实现这些,你可以在“Zone - Internet”组中增加一个子组,就像下面那样:
caspol -ag 1.3 -site www.mydomain.com FullTrust
现在如果你运行 caspol -lg 就可以看到新的代码组被增加为 1.3.1 组:
...
   1.3.  Zone - Internet: Internet
      1.3.1.  Site - www.mydomain.com: FullTrust
...
注意数字标号 (1.3.1) 只是 caspol 编出来以便能从命令行方便地操纵代码组的。底层的运行库永远看不到它。
 
7.5 如何改变代码组的权限集?
使用 caspol。如果你是机器的管理员,你能在 machine 层次上操作—这不仅意味着你所做的改变将成为机器的默认设置,而且用户不能把权限改得更宽。如果你是一个普通用户 (不是管理员) 你仍然可以修改权限,但只能使它们变得更严格。例如,为使 intranet 代码能做它们想做的事,你可能需要这样:
caspol -cg 1.2 FullTrust
注意,因为 (在标准的系统里) 这比默认的安全策略权限更大,你应该在 machine 层次上做这些—在 user 层次上这样做不起作用。
 
7.6 能否创建自己的权限集?
是的。使用 caspol -ap,指定一个包含权限集中所有的权限的 XML 文件。这里 是一个指定 Everything 权限集的示例文件—修改它以适应你的需要,这样可以节省一些时间。修改完成后,用以下方法将它添加到可用的权限集中:
caspol -ap samplepermset.xml
然后,用以下方法将此权限集施加到一个代码组上:
caspol -cg 1.3 SamplePermSet
(默认情况下,1.3 是 Internet 代码组)
 
7.7 CAS 有问题时,如何诊断自己的程序?
caspol 有一组可能有用的选项。首先,使用 caspol -rsg,你能让 caspol 告诉你一个元件属于哪一个代码组。类似地,使用 caspol -rsp,你能询问在特定元件上施加了什么权限。
 
7.8 我受不了 CAS 带来的麻烦,能否关掉它?
是的,只要你是系统管理员。只要运行:
caspol -s off
 
8. 中间语言 (IL)
8.1 我能看到元件的中间语言吗?
是的。Microsoft 提供了一个称为 Ildasm 的工具,它可以用来查看元件的 metadata 和 IL。
 
8.2 能否通过反向工程从 IL 中获得源代码?
是的。相对而言,从 IL 来重新生成高级语言源代码 (例如 C#) 通常是很简单的。
 
8.3 如何防止别人通过反向工程获得我的代码?
目前唯一的办法是运行带有 /owner 选项的 ilasm。这样生成的元件的 IL 不能通过 ildasm 来查看。然而,意志坚定的代码破译者能够破解 ildasm 或者编写自己的 ildasm 版本,所以这种方法只能吓唬那些业余的破译者。
不幸的事,目前的 .NET 编译器没有 /owner 选项,所以要想保护你的 C# 或 VB.NET 元件,你需要像下面那样做:
csc helloworld.cs
ildasm /out=temp.il helloworld.exe
ilasm /owner temp.il
(这个建议是 Hany Ramadan 贴到 DOTNET 上的。)
看起来过一段时间能有 IL 加密工具 (无论来自 Microsoft 或第三方)。这些工具会以这样的方式来“优化” IL:使反向工程变得更困难。
当然,如果你是在编写 Web 服务,反向工程看起来就不再是一个问题,因为客户不能访问你的 IL。
 
8.4 我能直接用 IL 吗?
是的。Peter Drayton 在 DOTNET 邮件列表里贴出了这个简单的例子:
.assembly MyAssembly {}
.class MyApp {
  .method static void Main() {
    .entrypoint
    ldstr      "Hello, IL!"
    call       void System.Console::WriteLine(class System.Object)
    ret
  }
}
将其放入名为 hello.il 的文件中,然后运行 ilasm hello.il,将产生一个 exe 元件。
 
8.5 IL 能做到 C# 中做不到的事吗?
是的。一些简单的例子是:你能抛出不是从 SystemException 导出的异常,另外你能使用非以零起始的数组。
 
9. 关于 COM
9.1 COM 消亡了吗?
就像你在邮件列表中看到的那样,这个主题导致了激烈的争论。看看以下两个地方:
http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&D=0&P=68241
http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&P=R60761
我的理解是:COM 包含很多内容,并且对于不同的人而言它是不同的东西。但是对我来说,COM 基本上是关于一小段代码如何找到另一小段代码,以及当它们相互找到后该如何相互通讯。COM 准确地指明了这种定位和通讯该如何进行。在完全由 .NET 对象构成的“纯” .NET 世界里,小段代码依然相互寻找并相互交谈,但它们不使用 COM 来做这些。它们使用在某些地方和 COM 很相像的一种模型—例如,类型信息保存在和封装在一起的表单中,这和在 COM 组件中封装一个类型库十分相似。但它不是 COM。
所以,这里有什么问题吗?好吧,我确实不关心大多数 COM 消失了—我不关心寻找组件不再和注册表有关,我也不使用 IDL 来定义我的借口。但有一件东西我不希望它消失—我不希望失去基于接口的开发这种思想。照我看来,COM 最强大的力量是它坚持在接口和实现之间竖起铸铁般的隔墙。不幸的是,看来 .NET 不再那样坚持—它允许你做基于接口的开发,但它并不坚持。一些人可能会辩解说有一个选择总不会是坏事,可能他们是对的,但我不能不觉得这可能是一个退步。
 
9.2 DCOM 消亡了吗?
差不多是,尤其是对于 .NET 开发者。.NET 框架有一个不基于 DCOM 的新的远程模型。当然 DCOM 还会在互操作场合下使用。
 
9.3 MTS/COM+ 消亡了吗?
不。第一个 .NET 版本考虑的是提供对现有 COM+ 服务 (通过一个互操作层) 而不是使用 .NET 自己的服务来取代它们。很多工具和属性被用以实现尽可能平滑的过渡。.NET SDK 的 PDC 版本包括对核心服务 (JIT 活动、事务) 的支持,但不包括一些高层服务 (例如 COM+ 事件、队列化组件)。
在一段时间内看来,互操作性可以预期是无缝集成的—这意味着一些服务将成为 CLR 的一部分,并且/或者意味着一些服务将以可管理代码的形式重写并运行在 CLR 的顶层。
关于这个主题,参见 Joe Long 的贴子—Joe 是 Microsoft 的 COM+ 组的经理。从这里开始:
http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&P=R68370
 
9.4 能在 .NET 中使用 COM 组件吗?
可以。可以通过 Runtime Callable Wrapper (RCW) 从 .NET 中访问 COM 组件。它通过将 COM 组件映射为与 .NET 兼容的接口来使 COM 接口可以被访问。对于 oldautomation 接口,可以自动地从一个类型库中产生。对于非 oleautomation 接口,可以开发一个定制的 RCW,以便手工地将 COM 接口的类型映射为与 .NET 兼容的类型。
对于熟悉 ATL 的读者,这里有一个简单的示例。首先,创建一个 ATL 组件以实现以下 IDL:
import "oai