虚拟机隔离运行模型.docx
《虚拟机隔离运行模型.docx》由会员分享，可在线阅读，更多相关《虚拟机隔离运行模型.docx（64页珍藏版）》请在冰点文库上搜索。
虚拟机隔离运行模型
第三章隔离运行模型
本章提出了一种新的基于虚拟机技术的隔离运行模型—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）处理器必须提供一种保护机制或地址转换机制，能够对物理计算机系统和虚拟机之间进行隔离和保护。
这一约束与Goldberg提出的约束3一致。
约束3（R3）当虚拟机试图执行敏感指令（SensitiveInstruction）时，处理器必须提供一种机制使得虚拟机监视器能够自动得到通知，以便于其模拟出该指令的执行语义。
按照JohnScottRobin等的定义，敏感指令就是指所有需要操作虚拟机监视器或宿主操作系统状态的指令，主要包括如下四类指令：
1.读写当前虚拟机和物理计算机系统状态的指令；
2.读写敏感寄存器和内存的指令，例如读写时钟寄存器或中断寄存器的指令；
3.操作处理器提供的保护机制或是地址转换机制的状态的指令；
4.所有I/O指令。
x86处理器满足Goldberg提出的四个约束：
具有从0-3四种特权级（PrivilegeLevel），操作系统内核运行在Ring0级，而应用程序则运行在最低特权级上—Ring3级；提供了调用门（CallGate）机制，用以支持低特权级的程序调用高特权级的代码；提供了段/页式内存管理机制，以支持内存重定位和保护；提供了中断（Interrupt）和异常（Exception）两种机制使得I/O设备可以与处理器异步通信。
图3.3处理器指令分类
同理，Intelx86处理器也满足JohnScottRobin约束R1和R2，但是它依然不支持虚拟化，这是因为它不能满足约束R3。
如图3.3所示，从处理器虚拟化和处理器特权级两个角度审视指令集，可将其分为四类：
特权非敏感指令、非特权非敏感指令、特权敏感指令和非特权敏感指令。
由于前两种均为非敏感指令，所以可以在物理处理器上直接执行，无需虚拟机监视器做特殊处理。
但是，正如处理器约束所规定的，虚拟机监视器必须解释执行所有敏感指令的语义而不能在物理处理器上直接执行。
对于x86处理器而言，所有特权敏感指令的执行均会产生中断或自陷（Trap），因此虚拟机监视器可以通过设置相应的中断/自陷响应函数获得通知进而进行指令模拟。
而使得x86处理器不支持虚拟化的就是第四类指令—非特权敏感指令，与其它支持虚拟化的处理器不同，x86处理器的指令集中存在非特权敏感指令，而这类执行的执行并不产生任何中断或自陷，从而虚拟机监视器无法获取相应的通知信息。
JohnScottRobin等已经分析了x86处理器的所有指令，指出其中包含了17条非特权敏感指令，即SGDT、SIDT、SLDT、SMSW、PUSHF（PUSHFD）、POPF（POPFD）、LAR、LSL、VERR、VERW、POP、PUSH、CALL,JMP、INTn、RET和STR。
综上所述，在x86处理器上实现SVEEVMM（TypeIIVMM）的关键就是如何模拟执行敏感指令，并且感知非特权敏感指令的执行。
目前有三种方法可以处理非特权敏感指令：
第一种技术是Denali和Xen的半虚拟化技术，但是这种技术需要修改操作系统源代码，不能满足SVEE隔离运行模型的约束2A；第二种技术是Intel和AMD提出的硬件虚拟化技术，该技术通过修改处理器的实现使得处理器在虚拟化状态下执行非特权敏感指令时能够产生事件通知虚拟机监视器；但是考虑支持硬件虚拟化技术的处理器尚未普及，因此SVEEVMM采取了第三种技术，即“动态指令转换技术”，使得SVEEVMM通过运行时指令转换将原本不产生自陷的非特权敏感指令替换为具有通知VMM功能的指令。
3.2.2基于卷快照的虚拟简单磁盘
对于本地虚拟化技术而言，关键问题是如何与宿主操作系统共享已安装在系统卷上的操作系统映像。
因为SVEE虚拟机需要访问系统卷以启动Local-BootedOS，而此时宿主操作系统也在修改系统卷，前者对数据的修改并没有使用宿主操作系统提供的访问接口，后者的修改信息也无法及时被SVEE虚拟机内的文件系统感知，这就造成了文件系统数据与磁盘数据的冲突，操作系统关键文件的不一致将会导致系统的崩溃。
为了解决这个问题，本文提出了基于卷快照的虚拟简单磁盘（VirtualSimpleDisk）技术。
卷快照是在其创建时刻它所对应的原始卷的一致性副本，它提供了与文件系统标准卷相同的访问接口。
而虚拟简单磁盘则是卷快照（必须包括系统卷的快照）与虚拟分区表的集合，它是将卷快照以存储设备的形式导出到SVEE虚拟机的实现方式。
此外，在将卷快照导出到SVEE虚拟机前，用户可以安全删除不允许在Local-BootedOS中访问的目录、文件等敏感数据。
从实现的角度，创建整个磁盘的快照比导出卷快照的方式更加直观。
但是对于SVEE来说，组合卷快照的虚拟简单磁盘主要有如下三个优势：
●便于配置导出的卷：
如直接使用磁盘快照，则该磁盘内所有的卷均会被导出到SVEE虚拟机中，这往往违背了用户的安全性和可配置性的需求。
而通过配置虚拟简单磁盘，只有用户明确需要导出的卷才能在SVEE虚拟机中访问；
●卷格式透明：
目前广泛应用的操作系统均支持多种卷格式，如单分区卷与多分区卷等，多分区卷包括镜像卷（MirrorVolume）、RAID-0卷和RAID-5卷等。
所以如果直接导出磁盘快照，那么如该磁盘内含有多分区卷，则也必须导出该卷依赖的所有磁盘。
但是以卷快照为导出的基本单位则避免了这个问题。
●便于操作快照数据：
卷是文件系统加载的基本单位。
通过加载卷快照，用户可以方便直观地访问快照数据。
3.2.3操作系统动态迁移管理器
基于卷快照的虚拟简单磁盘解决了文件系统的冲突问题，但本地虚拟化技术的实现还需要解决软件服务的不兼容问题。
由于SVEE虚拟机是直接从宿主操作系统启动，因此所有启用的系统服务和开机自动运行的软件都将在SVEE虚拟机启动时运行。
由于SVEE虚拟机与宿主硬件环境的差异，依赖于硬件系统的系统服务可能会导致SVEE虚拟机启动时挂起甚至崩溃。
为了解决这个问题，本文引入了隐式进程标识技术（将在第六章介绍），该技术能够在虚拟层标识客户操作系统中的进程（包括当前进程），而无需依赖于任何操作系统API。
结合此技术与SVEEVMM获取的Local-BootedOS的内存信息，操作系统动态迁移管理器能够确定导致Local-BootedOS挂起或崩溃的进程，进而将这些信息自动记录到不兼容服务数据库。
此后，在启动SVEE虚拟机前，操作系统动态迁移管理器将在Local-BootedOS中自动禁用所有不兼容服务数据库中的服务。
3.2.4修改跟踪管理器
为了满足约束4（隔离程序执行效果的跟踪），SVEE需要监视Local-BootedOS中的数据修改信息，为此本文引入了修改跟踪过滤驱动（ChangeTrackingFilterDriver，CTFD）以监视和记录文件的修改操作。
而为了支持提交Local-BootedOS中的修改结果到宿主操作系统，则需要同时在这两个操作系统中布署CTFD。
监视不同对象的修改信息需要实现不同的过滤驱动，如需要文件系统过滤驱动来实现对文件的监视，而对Windows注册表的监视则需要利用系统调用拦截技术。
SVEE运行结束时，可以向用户提供三种操作：
放弃SVEE内隔离程序的执行结果、保留执行结果和提交执行结果到宿主操作系统。
对于第一种情况，SVEE虚拟机的整个运行环境将被销毁，之后启动的SVEE虚拟机均需要重新创建新的虚拟简单磁盘；若保留执行结果，则仅关闭SVEE虚拟机，而不销毁虚拟简单磁盘；对于第三种情况，需要利用修改跟踪管理器来分析和比较SVEE虚拟机从创建到结束整个过程中Local-BootedOS和宿主操作系统的数据变化，进而进行修改合并，而合并的同时还需要解决可能发生的各种冲突。
从安全的角度考虑，提交来源非可信软件的执行结果到宿主操作系统是不可取的，但对于质量非可信软件（不稳定代码和存在脆弱性代码）的执行结果而言还是有应用需求的。
3.2.5隐式操作系统信息重构组件
为了满足约束5（支持操作系统信息重构），SVEE需要提供一种能够在虚拟层获取操作系统语义信息的通用机制，包括进程、文件、网络、内存和注册表等关键的系统信息。
由于客户操作系统的内部状态对虚拟机来说是完全透明的，因此隐式操作系统信息重构组件需要利用虚拟层有限的硬件视图信息，重构出操作系统的语义信息。
为此，本文提出了一种新的隐式操作系统信息重构平台（ImplicitOSInformationReconstructionPlatform，IOIRP）。
利用该技术，隐式操作系统信息重构组件能够在不借助操作系统API的情况下，利用硬件层的信息重构出操作系统的语义信息。
第四章隔离运行环境的功能完整性问题
由于程序功能的正常执行与执行效果通常依赖于计算环境，尤其是文件系统内容与操作系统配置等。
因此，提升隔离运行环境的功能完整性需要在该环境内重现宿主操作系统的计算环境。
本章将详细描述实现计算环境重现的基础—本地虚拟化技术。
为了解决在SVEE虚拟机中重用已有软件环境所带来的文件系统冲突和软硬件配置兼容性等问题，本章提出了基于卷快照的文件系统共享技术与操作系统动态迁移技术。
测试结果表明卷快照技术带来的I/O性能下降小于10%，处理器开销仅增加约3%，而动态迁移技术使得SVEE能够有效支持多种不同软硬件配置的计算机系统。
由于目前个人计算平台下最普及的配置是微软的Windows操作系统与Intel的x86处理器，因此，SVEE首先在面向x86处理器的Windows平台下实现原型系统。
4.1基于卷快照的文件系统共享
对于本地虚拟化技术而言，关键问题是如何直接使用宿主操作系统的安装映像。
尽管SVEE虚拟机与宿主操作系统共享系统卷，但是这二者均不能感知彼此对系统卷数据的修改，这将导致Loca-BootedOS和宿主操作系统的文件系统数据与磁盘数据的冲突，进而使系统崩溃。
解决此冲突的充要条件是这两个操作系统的文件系统对本系统内磁盘数据的修改均是封闭的，即不会影响另一个操作系统内的磁盘数据。
为了给出此充要条件的形式化定义并为下一步的算法正确性分析做准备，首先定义了如下两个函数：
函数Write（OS,Block,t）：
表示时刻t，操作系统OS的文件系统修改了该操作系统内的卷数据块Block。
函数的返回值即为写入的内容，若返回值为Φ，则表示时刻t未修改数据块Block。
其中OS∈{Local-BootedOS,HostOS}。
函数Read（OS,Block,t）：
表示时刻t，操作系统OS的文件系统读该操作系统内的卷数据块Block，函数的返回值即为该数据块的内容。
基于上述定义，充
升级会员 