搜索
第三章隔离运行模型本章提出了一种新的基于虚拟机技术的隔离运行模型—SVEE，该模型满足满足操作系统隔离、应用透明、计算环境重现、隔离程序执行效果跟踪与操作系统信息重构等五个应用约束，平衡了安全隔离性、功能完整性、性能适应性和行为可监控性。同时，本章给出了该模型的形式化安全性分析和度量，通过理论分析阐明了SVEE能够满足Bell-LaPadula机密性模型和Biba完整性模型。并进一步论证了在此模型下，被保护的宿主环境的容侵能力也将得到有效提升。基于此模型，本章构造出以本地虚拟化技术为核心的满足SVEE隔离运行模型的体系结构，该体系结构独立于操作系统实现，具有很好的可移植性。通过对现有虚拟机模型的详细分析，指出TypeII虚拟机模型能够最有效地在个人计算平台下支持这五个约束条件。本章工作是后继章节所做工作的理论基础。3.1隔离运行模型对于隔离运行非可信软件的运行环境而言，为了实现操作系统与应用程序透明的目标，同时能够重现已有的软件运行环境并支持操作系统语义信息的重构，即在保证安全隔离性的前提下提升隔离运行环境的功能完整性、性能适应性与行为可监控性，该环境必须满足以下约束条件。约束1：操作系统隔离：非可信软件必须运行在一个与宿主操作系统隔离的虚拟计算机系统中，这是抵御特权恶意代码攻击、确保安全隔离性的必要条件。约束2：应用程序与操作系统透明：现有操作系统、应用程序和将被隔离的非可信软件均不需作任何修改即可直接布署该隔离机制，这一点在个人计算平台下尤其重要。此约束包含四个子约束：约束2A：无需修改现有操作系统与应用程序及其将被隔离的非可信软件的源代码，因为通常个人计算平台上流行的应用程序与操作系统（如Windows）都未开放源代码。约束2B：不能限制非可信软件在隔离运行环境内访问的资源与执行的特权操作，这是保证隔离运行环境的功能完整性的必要条件。约束2C：尽可能地将隔离机制对可信代码运行环境造成的性能影响最小化，即在确保安全隔离性的同时兼顾系统的可用性。约束2D：无需重新安装现有操作系统。个人用户中绝大部分不是计算机专业技术人员，所以个人计算平台上往往都预装有操作系统，所以在布署隔离运行技术时必须保证能够继续使用原有操作系统。约束3：可配置的计算环境重现：由于非可信软件的正常执行与执行效果通常依赖于计算环境，尤其是文件系统内容与操作系统配置等，所以在隔离运行环境内重现宿主操作系统的计算环境既是保证隔离运行环境的功能完整性的要求，也是减少布署开销的必要条件。本约束可细化为：约束3A：计算环境的重现不应通过复制整个计算机的软硬件系统的来实现，这样的布署开销通常不能被个人用户接受。约束3B：为了提高系统机密性，被导出到隔离运行环境中的宿主计算环境资源应该是可配置的，被隔离软件只能访问这些资源，涉及敏感信息的数据不应在隔离运行环境中重现。这是确保安全隔离性的必要条件。约束3C：尽可能地使隔离运行环境的性能接近宿主环境，这是提升性能适应性的要求。约束4：隔离程序执行效果的跟踪：隔离运行环境必须能够跟踪和记录被隔离软件对数据的修改操作，从而为分析程序行为与提交相应程序的执行效果到宿主环境提供依据，这也是提高系统可用性与隔离运行环境的行为可监控性的关键。约束5：支持操作系统语义信息重构：这里的语义信息是指操作系统抽象层的资源的信息，如进程、线程、文件、用户等。用户或相关工具程序只有借助隔离运行环境的这些信息才能精确分析隔离运行环境内应用程序和操作系统的行为，进而提升隔离运行环境的行为可监控性。(a)基于TypeIVMM的Native隔离运行模型(b)基于TypeIIVMM的Hosted隔离运行模型图3.1SVEE的基于不同VMM的两种可选隔离运行模型为了满足约束1，SVEE必须利用虚拟机监视器（VirtualMachineMonitor，VMM）来创建非可信软件的运行容器—虚拟机。只有这种基于硬件抽象层的虚拟机技术才能实现操作系统的隔离。按照Goldberg的定义，VMM是能够为计算机系统创建高效、隔离的副本的软件。这些副本即为虚拟机（VirtualMachine，VM），在虚拟机内处理器指令集的一个子集能够直接在物理处理器上执行。Goldberg定义了两种VMM：TypeIVMM和TypeIIVMM。TypeIVMM直接运行在计算机硬件系统上，负责调度和分配系统硬件资源，可以将其理解为一个实现了虚拟化机制的操作系统。而TypeIIVMM则以一个应用程序的形式运行在已有的传统操作系统之上，而这个实际控制系统资源的操作系统被称为宿主操作系统（HostOS），运行在TypeII虚拟机中的操作系统则被称为客户操作系统（GuestOS）。基于这两种不同的虚拟机监视器，SVEE就有了相应的两种隔离运行模型（如图3.1所示）：基于TypeIVMM的Native隔离运行模型和基于TypeIIVMM的Hosted隔离运行模型。对于约束2A，作为硬件抽象层的虚拟机，Native隔离运行模型中的TypeIVMM与Hosted隔离运行模型中的TypeIIVMM均无需修改已有应用程序和将被隔离的非可信软件的源代码。TypeIIVMM的实现不需要修改宿主操作系统，而TypeIVMM是否需要修改操作系统则依赖于其实现技术，如基于动态指令转换技术则无需修改（如VMwareESXServer），基于半虚拟化技术（Para-Virtualization）且没有硬件虚拟化技术的支持则需要修改运行在VMM之上的操作系统源代码（如Xen）。由于TypeIVMM与TypeIIVMM这两种虚拟机技术均对上层应用提供了完整的虚拟化计算机硬件平台，VMM之上运行的软件（操作系统）就像在真实的物理计算机系统上运行一样，无需限制代码访问的资源与执行的特权操作，因此这两种隔离运行模型均能满足约束2B。约束2C强调的是保证可信代码运行环境的性能。如图3.1(a)所示，在Native隔离运行模型中，所有操作系统都运行于虚拟机之上，所以不可避免地导致可信代码运行环境性能的下降。而基于TypeIIVMM的Hosted隔离运行模型的可信代码运行环境即为传统的操作系统，高效地直接运行于硬件系统之上。因此，在尽可能减少影响可信代码运行性能这一点上，基于TypeIIVMM的Hosted隔离运行模型优于Native隔离运行模型。而对于约束2D，在Native隔离运行模型中，需要用VMM替换原有的操作系统，这往往对于个人用户来说是无法接受的，而即使用户接受，要替换现在所有的个人计算平台上的操作系统也是一个非常漫长的过程。与此相反，Hosted隔离运行模型则可以与已有操作系统共存。约束3C关注的是隔离运行环境的性能可适应性。与TypeIVMM相比，TypeII虚拟机中的虚拟I/O设备性能不及TypeI虚拟机。但是随着硬件虚拟化技术的普及、应用与提高，以及各种虚拟I/O设备优化技术研究的不断发展，这种性能差距将逐渐缩小。约束3（3A和3B）、约束4和约束5均与具体的虚拟机监视器模型无关，而对于这三个约束，Native隔离运行模型和Hosted隔离运行模型均需要添加额外的机制才能支持，这也是3.2节（SVEE体系结构）需要解决的问题。此外，从软件开发的角度来看，Native隔离运行模型中的TypeIVMM实际上是将传统操作系统的硬件资源管理功能下移到VMM中。但在个人计算平台下这种机制有一个明显的不足：个人计算平台上硬件设备的多样化将会极大地增加TypeIVMM开发的复杂性。个人计算平台开放的体系结构导致计算机系统有类型繁多的硬件设备，而直接运行在硬件系统之上TypeIVMM则需要管理这些设备，因此为它们编写相应的驱动程序将是工程浩大的工作。与此不同，TypeIIVMM可以直接利用操作系统提供的设备抽象接口，极大简化VMM的开发，从而可以有效提高VMM的稳定性。综上所述，除了约束2C和约束2D，这两种隔离运行模型均能够满足其他约束。但是，由于SVEE主要针对的是个人计算平台，而Hosted隔离运行模型在个人计算平台下具有显著优势，因此SVEE采用了基于TypeIIVMM的Hosted隔离运行模型。在这种模型下，SVEEVMM以TypeIIVMM的形式运行在宿主操作系统之上，并负责创建本地化启动的SVEE虚拟机作为执行非可信软件的运行环境。运行在本地化启动的SVEE虚拟机之上的客户操作系统是宿主操作系统的一个副本，因此非可信软件在宿主操作系统上的行为得以精确重现，同时将其执行效果同宿主运行环境彻底隔离。3.2系统体系结构为了满足前文中描述的五个约束，SVEE引入了本地虚拟化技术（LocalVirtualizationTechnology）以实现可配置的计算环境重现。SVEE基于TypeIIVMM的Hosted体系结构如图3.2所示，SVEE由五个核心组件构成：SVEE虚拟机监视器（SVEEVMM）、基于卷快照（VolumeSnapshot）的虚拟机简单磁盘（VirtualSimpleDisk）、操作系统动态迁移管理器（OSDynamicMigrationManager）、修改跟踪管理器（ChangeTrackingManager）和隐式操作系统信息重构组件（ImplicitOSInformationReconstructor）。如SVEE隔离运行模型所述，SVEEVMM需要以TypeIIVMM的形式实现，即在宿主操作系统之上运行。SVEEVMM负责创建非可信软件的隔离运行环境—SVEE虚拟机（SVEEVM）。借助基于卷快照的虚拟机简单磁盘和操作系统动态迁移管理器，SVEE实现了本地虚拟化技术，即SVEE虚拟机中无需重新安装操作系统（这是现有虚拟机软件的运行模式），而是直接从宿主操作系统启动，启动后的操作系统即为“本地启动操作系统”（Local-BootedOS）。图3.2SVEE体系结构修改跟踪管理器则记录Local-BootedOS和宿主操作系统（HostOS）内的资源（如文件、注册表等）变化信息，为进一步分析被隔离软件的行为或之后将Local-BootedOS的数据变化合并到宿主操作系统提供支持。隐式操作系统信息重构组件不依赖于操作系统提供的接口，能够利用硬件层的数据（如处理器寄存器信息、MMU、磁盘信息等）重构出具有应用层语义的客户操作系统信息。3.2.1虚拟机监视器如前所述，SVEE虚拟机即为采用本地虚拟化技术启动的硬件抽象层虚拟机，被隔离的非可信软件就在由SVEE虚拟机启动的Local-BootedOS中运行，而可信程序则直接在宿主操作系统上运行。为了满足不能修改操作系统源代码的约束（约束2A），SVEEVMM不能采用半虚拟机技术，而只能采用与VMware虚拟机（包括VMwareWorkstation和VMwareESXServer）类似的动态指令转换技术。由于IntelPentium处理器（x86体系结构）在目前的个人计算平台上最为流行，因此SVEEVMM需要重点解决的就是如何在IntelPentium处理器上实现基于动态指令转换技术的TypeIIVMM。Goldberg分析并提出了适合虚拟化的第三代硬件体系结构应该满足的四点约束：1.具有两个以上的处理器操作模式。2.非特权的程序能够通过一种方法来调用特权级的系统例程。3.具有内存重定位或保护机制，如分段机制或分页机制。4.具有异步的中断机制。JohnScottRobin等人则提出了关于处理器支持TypeIVMM和TypeIIVMM需满足的约束。由于SVEEVMM是以TypeIIVMM的形式实现的，因此本文只讨论处理器支持TypeIIVMM需满足的约束条件。约束1（R1）无论在特权模式还是非特权模式下，非特权指令的执行语义都必须相同。例如，处理器不能通过在指令代码内添加特殊的比特位来标识处理器当前的特权级（CurrentPrivilegeLevel，CPL）。这个约束实际上是对Goldberg提出的约束1的一个扩展。约束2（R2）处理器必须提供一种保护机制或地址转换机制，能够对物理计算机系统和虚拟机之间进行隔离和保护。这一