计算机应用   2017, Vol. 7 Issue (2): 388-391  DOI: 10.11772/j.issn.1001-9081.2017.02.0388
0

引用本文 

赵成, 陈兴蜀, 金鑫. 基于硬件虚拟化的虚拟机文件完整性监控[J]. 计算机应用, 2017, 7(2): 388-391.DOI: 10.11772/j.issn.1001-9081.2017.02.0388.
ZHAO Cheng, CHEN Xingshu, JIN Xin. Virtual machine file integrity monitoring based on hardware virtualization[J]. JOURNAL OF COMPUTER APPLICATIONS, 2017, 7(2): 388-391. DOI: 10.11772/j.issn.1001-9081.2017.02.0388.

基金项目

国家自然科学基金资助项目(61272447)

通信作者

陈兴蜀(1969-),女,四川自贡人,教授,博士,主要研究方向:云计算、大数据、信息安全、可信计算. E-mail:chenxsh@scu.edu.cn

作者简介

赵成(1991-),男,河北固安人,硕士研究生,主要研究方向:云计算、虚拟化;
金鑫(1976-),男,辽宁营口人,博士研究生,主要研究方向:云计算、虚拟化、可信计算

文章历史

收稿日期:2016-08-15
修回日期:2016-09-02
基于硬件虚拟化的虚拟机文件完整性监控
赵成, 陈兴蜀, 金鑫    
四川大学 计算机学院, 成都 610065
摘要: 为保护虚拟机敏感文件的完整性,针对外部监控中基于指令监控方式性能消耗大、兼容性低和灵活性差等缺点,提出一种基于硬件虚拟化的文件完整性监控(OFM)系统。该系统以基于内核的虚拟机(KVM)作为虚拟机监视器,可动态实时地配置敏感文件访问监控策略;OFM可修改虚拟机系统调用表项以透明拦截文件操作相关系统调用,以监控策略为依据判定虚拟机进程操作文件的合法性,并对非法进程进行处理。在虚拟机中采用性能测试软件Unixbench进行仿真,其中OFM在文件监控方面优于基于指令的监控方式,且不影响虚拟机其他类型系统调用。实验结果表明,OFM可以有效地监控虚拟机文件的完整性,具有更好的兼容性、灵活性和更低的性能损耗。
关键词: 敏感文件    完整性    系统调用    硬件虚拟化    基于内核的虚拟机    
Virtual machine file integrity monitoring based on hardware virtualization
ZHAO Cheng, CHEN Xingshu, JIN Xin     
College of Computer Science, Sichuan University, Chengdu Sichuan 610065, China
Abstract: In order to protect the integrity of the Virtual Machine (VM) sensitive files and make up for the shortcomings such as high performance overhead, low compatibility and poor flexibility in out-of-box monitoring based on the instruction monitoring methods, OFM (Out-of-box File Monitoring) based on hardware virtualization was proposed. In OFM, Kernel-based Virtual Machine (KVM) was used as the virtual machine monitor to dynamically configure sensitive file access control strategy in real-time; in addition, OFM could modify the call table entries related to file operations of virtual machine system to determine the legitimacy of the VM process operation files, and deal with the illegal processes. Unixbench was deployed in a virtual machine to test the performance of OFM. The experimental results demonstrate that OFM outperforms to instruction monitoring methods in file monitoring and has no affect on other types of system calls for virtual machines. Meanwhile, OFM can effectively monitor the integrity of the virtual machine files and provide better compatibility, flexibility and lower performance losses.
Key words: sensitive file    integrity    system call    hardware virtualization    Kernel-based Virtual Machine (KVM)    
0 引言

随着计算机硬件及其技术的发展,云计算在科研、商用领域都得到了广泛的应用。美国国家标准与技术研究院(National Institute of Standards and Technology,NIST)发布的《完全虚拟化安全指南》[1]指出,云平台虚拟机与主机一样,都面临着恶意软件的威胁,如计算机病毒、木马等。由于敏感文件保存着用户的机密数据或系统重要配置信息,因此恶意软件对敏感文件的非法操作可能影响系统正常执行,泄露或篡改敏感信息,如《2015年7月计算机病毒疫情分析》[2]中列举的新型木马变种Trojan_Agent.WMU、Trojan_Zbot.LFM等。因此,监控系统敏感文件完整性,对于尽早发现恶意代码的攻击、保护隐私数据免遭恶意泄露或篡改具有重要作用。

目前,针对虚拟机内文件完整性监控方法,学术界有着多方面的研究。TripWire[3]和I3FS[4]都是用于检测主机文件完整性的工具,分别运行在用户态、内核态,通过度量文件的哈希值验证文件的完整性;Xen-FIT[5]和文献[6]的系统均基于Xen实现,通过在虚拟机中安装监控代理可实时检测虚拟机文件完整性。上述方法的不足是:1) 钩子地址和代理模块依赖于目标虚拟机版本,通用性差;2) 钩子函数和代理模块同样可能被虚拟机中的恶意软件攻击而失效。FSGuard[7]、XMonitor[8]、RFIM[9]通过在Hypervisor中透明地捕获虚拟机系统调用指令(int 0x80或syseter)以监控文件操作相关系统调用,验证虚拟机中文件的完整性,这种方法避免了虚拟机监控代理被恶意攻击的威胁,但与文件操作无关的系统调用同样会陷入到Hypervisor中而带来不必要的性能损耗。XenAccess[10]提供了虚拟机文件完整性校验的监控接口,但不包含功能性模块,只能实时监控目录或文件的创建和删除,无法提供对文件完整性的保护。

针对上述研究内容存在的不足,本文提出基于硬件虚拟化的虚拟机文件完整性监控方法,并实现了原型系统OFM(Out-of-box File Monitoring)。OFM在虚拟机外部实现,只需修改虚拟机文件操作相关系统调用表项,就能透明地捕获并分析虚拟机进程对敏感文件的操作;同时,通过管理和配置接口可以动态实时地配置敏感文件访问监控策略,无需重启云平台或虚拟机;OFM根据监控策略对虚拟机进程的文件操作进行分析,并处理非法文件操作的进程。OFM避免了虚拟机内部恶意软件的威胁,具有比现有方法更低的性能消耗,可动态配置的监控策略具有良好的可扩展性和灵活性,并可有效保护虚拟机文件完整性。

1 OFM系统设计

基于内核的虚拟机(Kernel-based Virtual Machine,KVM)[11]是基于硬件虚拟化技术实现的一个Linux内核模块,负责将宿主机底层硬件资源抽象成虚拟资源,并分配给虚拟机使用。KVM拥有特权级高、隔离性强和透明性好等特征,因此,在虚拟机运行过程中,KVM能够捕获虚拟机中的特定事件(敏感指令、中断或I/O)等,获取其内部语义,而虚拟机却无法感知到KVM的存在。硬件虚拟化需要Intel VT[12]或AMD-V[13]技术的支持,提供了Root和Non-Root两种运行模式,KVM运行在Root模式,而虚拟机运行于Non-Root模式。虚拟机陷入KVM的过程称为VM Exit,而由KVM返回虚拟机的过程称为VM Entry。

OFM是基于事件触发的主动监控框架,采用KVM作为VMM,总体架构如图 1所示。OFM实现了一种与虚拟机相隔离的文件完整性监控方法,能够动态设置所要保护的文件及其监控策略,保护其免受恶意代码的恶意攻击,如窃取或篡改敏感数据等。

图 1 OFM系统架构 Figure 1 OFM system architecture

在原型系统OFM中,捕获模块负责捕获虚拟机进程调用文件操作相关系统调用,通过虚拟机自省 (Virtual Machine Introspection,VMI)获取虚拟机内部语义信息,并将获取的信息传递到分析处理模块。分析处理模块接收捕获传递的虚拟机文件操作信息,读取策略库中文件操作监控策略,进行分析,将非法的操作信息写入日志。策略库存储虚拟机敏感文件监控策略,可以根据需要为具有权限的系统管理员提供管理和配置接口,进行实时动态的配置。策略库可以以数据库、文件等形式存在,完成监控策略配置后立即生效,无需重启云平台或虚拟机。日志存储虚拟机敏感文件的非法操作;同时,日志同样可以提供接口、离线分析等功能。

2 OFM系统设计 2.1 系统调用监控原理

图 2所示,在X86架构下,任意版本操作系统进程执行对文件的操作时,都需要调用应用层库函数提供的接口函数。接口函数则通过系统调用陷入指令(int、sysenter或syscall)调用内核层的系统调用服务程序,并利用EAX、EBX等寄存器传递参数信息,其中EAX存储系统调用号。当用户层程序切换进入内核层后,操作系统内核读取参数信息,根据系统调用号在系统调用表中进行索引,读取系统调用表项中存储的文件操作相关系统调用处理程序地址,跳转并执行。执行完毕后,通过系统调用返回指令(iret、sysexit或sysreturn)返回执行结果并恢复进程上下文,继续执行用户空间进程。

图 2 系统调用原理 Figure 2 System call principle
2.2 OFM实现原理 2.2.1 虚拟机page fault异常捕获

虚拟机控制结构(Virtual Machine Control Structure,VMCS)由KVM维护,负责保存虚拟机和宿主机发生切换时的硬件上下文环境,同时可以指定虚拟机发生陷入的特定事件。在操作系统中,访问非法地址引发系统产生page fault异常,而不同类型的page fault异常产生不同的error_code类型。为了能够在KVM中捕获虚拟机产生的特定类型page fault异常,需要对VMCS进行如下配置:

1) 将VMCS中EXCEPTION_BITMAP字段的PF_VECTOR位置1,使捕获模块可以捕获虚拟机中发生的page fault异常。

2) 在VMCS中将PAGE_FAULT_ERROR_CODE_MASK字段和PAGE_FAULT_ERROR_CODE_MATCH字段的值填充为特定值,使虚拟机中满足式(1) 的page fault异常类型才会发生VM Exit陷入KVM中,可以避免其他类型的page fault异常陷入KVM带来的不必要的性能损耗。

$PFEC\And PFEC\_MSAK=PFEC\_MATCH$ (1)

其中:PFEC表示虚拟机中不同类型page fault异常对应的error code,陷入KVM后保存在VMCS的VM_EXIT_INTR_ERROR_CODE字段;PFEC_MASK表示PAGE_FAULT_ERROR_CODE_MASK字段中的内容,设置为0x1F;PFEC_MATCH表示PAGE_FAULT_ERROR_CODE _MATCH中的内容,设置为0x10。

2.2.2 虚拟机文件操作相关系统调用拦截

本文将虚拟机系统调用表中与文件操作有关的表项分别填充为一个唯一的非法地址,当虚拟机进程调用此系统调用时,将因访问非法地址产生page fault异常,被OFM捕获模块捕获,并读取参数信息,进行分析,具体过程如下:

1) 在虚拟机启动加载内核至虚拟机内核空间完毕后,根据式(2) ,利用VMI机制修改虚拟机系统调用表中文件操作相关的表项为唯一的非法地址标识,并在策略库中保存原地址。

2) 当虚拟机调用这些系统调用时,将由于访问非法地址而发生page fault异常,并陷入到KVM的捕获模块。

3) 捕获模块读取虚拟机EIP寄存器中存储的非法地址,根据式(2) 判定系统调用类型,随后读取虚拟机EAX、EBX、ECX等寄存器中存储的系统调用参数,并利用参数,使用KVM提供的函数kvm_read_guest_virt_system()获取具体的参数内容,主要包括文件名称和操作方式等。

4) 捕获模块读取虚拟机ESP寄存器中保存的栈指针,获取虚拟机内核栈顶存储的thread_info结构体,根据thread_info结构体中的进程描述符指针,进一步利用kvm_read_guest_virt_system()读取虚拟机当前进程描述符,从中获取虚拟机当前进程名称。

5) 捕获模块将获取的进程名称、文件名称和操作方式传递到分析处理模块,分析处理模块结合策略库中的敏感文件监控策略,进行进一步的处理。

$Entr{{y}_{(SysCallTblAddr+N*AddrSize)}}=ErrBaseAddr-N$ (2)

式(2) 表示将系统调用表中需要被拦截系统调用对应的表项修改为非法地址,每个表项对应一个唯一的非法地址。Entry表示系统调用表中需要被拦截的系统调用对应的表项;SysCallTblAddr表示系统调用表基地址;N为被拦截系统调用的系统调用号;AddrSize表示地址宽度;ErrBaseAddr为非法地址基值,如本文针对32位虚拟机取0xFFFFFFFF。对于不同的系统调用表项,由于ErrBaseAddr取值相同而N不同,可以保证填充的非法地址的唯一性。

2.2.3 虚拟机文件完整性保护方法

为了保护虚拟机敏感文件的完整性,KVM中分析处理模块对虚拟机当前进程操作敏感文件的行为进行分析与处理,流程如下:

1) 分析处理模块接收捕获模块的参数信息后,读取策略库中的监控策略,判断当前进程对敏感文件的访问权限。

2) 若访问权限为允许,则直接放行;若访问权限为禁止,则将虚拟机EAX、EBX、ECX等寄存器修改为非法值,并将此非法操作信息写入日志文件。

3) 取出策略库中对应的虚拟机系统调用处理程序原地址,装入虚拟机EIP寄存器,通过VM Entry恢复虚拟机正常执行流程。

OFM截获系统调用分析与处理时刻,是虚拟机中进程利用调用门进入内核空间时刻,此时并未对文件进行实际访问。因此,通过修改虚拟机寄存器中系统调用的参数,可以使虚拟机系统调用函数直接返回一个错误值,避免敏感文件的非法操作及敏感文件内容的泄露。

2.3 监控策略

在原型系统OFM中,策略库由宿主机进行维护。策略库可以以数据库、文件等形式存在,存储虚拟机敏感文件监控策略。同时,可以根据实际需要,预留配置和管理接口,具有权限的管理员可通过接口动态实时地更新策略,并且更新完成后立即生效,无需重启云平台或者虚拟机。

本文给出虚拟机敏感文件监控策略的一种参考格式:

SysCallNum ProName SenFilName SenFilOp OpAuth

其中:SysCallNum表示虚拟机被拦截系统调用对应的系统调用号;ProName表示虚拟机进程名;SenFilName表示虚拟机中的敏感文件名;SenFilOp表示虚拟机中进程对敏感文件的操作;OpAuth表示虚拟机进程对敏感文件操作的权限,由策略制定者规定,如允许、禁止等。

3 测试与分析

本章描述原型系统OFM的功能测试和性能测试结果。如表 1,本文拦截了虚拟机中文件操作相关的系统调用,监控虚拟机进程对敏感文件的操作,并建立了支持不同系统调用指令的虚拟机进行测试,验证虚拟机文件完整性监控功能。

表 1 OFM截获系统调用类型 Table 1 System call types of OFM intercepts

实验环境:主机硬件配置为戴尔 OptiPlex 9020;处理器为Intel Core i5-4570 @1.86 GHz,4核;内存为12 GB DDR3 1600 MHz;宿主机为CentOS6.5,内核版本3.10.1 ,KVM版本3.10.1,QEMU版本1.7.1;虚拟机性能测试工具为unixbench-5.1.2。

3.1 功能测试

以支持sysenter指令的32位Linux虚拟机为例,测试原型系统OFM的功能。虚拟机配置:操作系统 CentOS6.5,内核版本为2.6.32 ,内存1 GB,VCPU数量1个。实验的目的是为了验证OFM是否可以保护虚拟机敏感文件不受非法破坏,过程如下。

在虚拟机的根目录下创建文本文件test.txt作为被保护的测试文件。通过监控策略配置端口,在策略库中添加控制策略如下:

1) 5  test1 /test.txt open allow:虚拟机进程test1对虚拟机文件/test.txt的open操作是允许的;

2) 5  test2 /test.txt open forbid:表示虚拟机进程test2对虚拟机文件/test.txt的open操作是禁止的。

为验证策略的有效性,虚拟机进程test1与test2的可执行文件由同一源程序生成。测试程序如下:

  #include<stdio.h>

  #include<stdlib.h>

  #include<fcntl.h>

  int main(void)

  {int fd;

 fd=open("/test.txt",O_RDWR);

  if(fd<0)

  {printf("No File\n");

  return 0;

  }

  printf("Yes File\n");

  return 0;

  }

为方便测试结果显示,OFM将虚拟机测试过程显示在虚拟机终端,虚拟机进程对敏感文件访问信息显示在宿主机终端,测试结果如图 3图 4

图 3 虚拟机测试过程 Figure 3 Virtual machine testing process
图 4 宿主机监控信息 Figure 4 Host monitoring information

根据图 3中虚拟机测试过程所示,当使用源文件test.c生成可行性文件test1和test2后运行,进程test1可以对文件/test.txt进行正常访问,而进程test2则无法找到该文件,其原因是OFM在KVM中捕获两个进程对文件的访问,并根据监控策略,分别进行了处理,捕获内容如图 4所示。通过实验结果可以看到,OFM可以有效监控虚拟机进程对敏感文件的操作信息,同时对虚拟机敏感文件的非法操作可有效禁止,保护了虚拟机文件完整性。

3.2 性能测试

本文分别建立sysenter、int和syscall指令的Linux虚拟机,并使用Unix 类操作系统微观基准测试工具Unixbench测试OFM的性能,评分越高代表性能越好。测试内容主要包括以下几个方面:CPU性能测试、磁盘I/O性能测试、系统调用性能测试和shell测试。

图 5~7所示,OFM能够在支持sysenter、int和syscall指令的虚拟机正常工作,说明OFM具有较好的兼容性。在CPU性能测试方面,浮点数操作项测试浮点数操作速度,其性能几乎不变;在磁盘I/O性能测试方面,文件拷贝项性能下降明显,主要原因是OFM拦截了读写文件相关的系统调用,并在KVM中引入了额外的处理流程,而在极端的测试环境下文件操作是极为频繁的;在系统调用性能测试中,Excel执行和系统调用项分别利用每秒钟Execl 系统调用和getpid系统调用的执行次数测试系统调用性能,两个系统调用均未被OFM拦截,但Excel系统调用涉及到文件操作,所以Excel执行项会出现少量的性能损耗,而系统调用项性能基本不变;最后,Unixbench的shell脚本项可以测试并发执行若干脚本模拟真实运行环境,其性能消耗很小。

图 5 支持sysenter指令的虚拟机性能测试 Figure 5 Virtual machine performance testing with sysenter instruction
图 6 支持int指令的虚拟机性能测试 Figure 6 Virtual machine performance testing with int instruction
图 7 支持syscall指令的虚拟机性能测试 Figure 7 Virtual machine performance testing with syscall instruction

文献[14]通过改变系统调用陷入指令正常运行条件,可在VMM中捕获并分析虚拟机系统调用行为。由于其捕获原理相同,因此仅以拦截sysenter指令为例,与OFM对比拦截虚拟机文件操作相关系统调用的性能。结果如图 8所示,在CPU性能测试方面,浮点数操作项因不涉及系统调用过程,性能没有明显变化。在磁盘I/O性能测试方面,文件拷贝项调用了与文件操作相关的系统调用,因此两种方法性能消耗明显,但是由于基于sysenter指令的系统调用拦截方法默认拦截所有系统调用,因此性能消耗更为严重。在系统调用性能测试中,Excel执行项通过Excel系统调用完成测试,涉及到部分文件操作,而系统调用项则单纯利用getpid系统调用测试,通过对比可以看出,本文方法只会产生少量的性能消耗,而拦截sysenter指令方法由于拦截全部系统调用,因此性能损耗更高;最后,在shell脚本测试项中,两种方法性能损耗都在合理范围内,但OFM更小。通过对比可以看出,OFM相比基于指令的虚拟机文件操作相关系统调用拦截分析方法,在提升灵活性的同时,也降低了虚拟机中不必要系统调用陷入带来的额外的性能损失。

图 8 性能对比结果 Figure 8 Performance comparison results
4 结语

本文通过在KVM中修改虚拟机系统调用表,截获了虚拟机中与文件操作有关的系统调用,实现了对虚拟机文件完整性的监控。与现有方法相比,本文方法具有更好的兼容性、灵活性,且性能损耗更低。但本文方法也存在如下不足:1)需要人工获取虚拟机系统调用表的位置;2)策略定义不够完善,处理过程也较为单一。下一步的研究工作就是针对以上不足进行研究,提高获取虚拟机内部数据的透明性,并对异常进程进行限制。

参考文献
[1] 王惠莅, 杨晨, 杨建军. 美国NIST云计算安全标准跟踪及研究[J]. 信息技术与标准化, 2012 (6) : 51-54. ( WANG H L, YANG C, YANG J J. Research on clouds computing security standards of NIST[J]. Information Technology & Standardization, 2012 (6) : 51-54. )
[2] 张蕴菁, 刘威. 2015年7月计算机病毒疫情分析[J]. 信息网络安全, 2015 (9) : 292-292. ( ZHANG Y J, LIU W. Analysis of computer virus epidemic situation in July, 2015[J]. Netinfo Security, 2015 (9) : 292-292. )
[3] KIM G H, SPAFFORD E H. The design and implementation of tripwire:a file system integrity checker[C]//CCS'94:Proceedings of the 2nd ACM Conference on Computer and Communications Security. New York:ACM, 1999:18-29.
[4] PATIL S, KASHYAP A, SIVATHANU G, et al. FS:an in-kernel integrity checker and intrusion detection file system[C]//LISA'04:Proceedings of the 18th USENIX Conference on System Administration. Berkeley, CA:USENIX Association, 2004:67-78.
[5] QUYNH N A, TAKEFUJI Y. A novel approach for a file-system integrity monitor tool of Xen virtual machine[C]//ASIACCS'07:Proceedings of the 2nd ACM Symposium on Information, Computer and Communications Security. New York:ACM, 2007:194-202.
[6] WANG Z Y. Monitoring system for disk file operations in Xen Full virtualization[J]. Xi'an:Xidian University, 2013 : 5-7.
[7] 王铸, 黄涛, 文莎. 基于虚拟机的文件完整性监控系统[J]. 中州大学学报, 2009, 26 (5) : 121-123. ( WANG Z, HUANG T, WEN S. A file integrity monitoring system based on virtualization[J]. Journal of Zhongzhou University, 2009, 26 (5) : 121-123. )
[8] WANG T T. Research and implementation of virtual machine based on hardware-assisted virtualization[J]. Beijing:Beijing University of Posts and Telecommunications, 2015 : 3-4.
[9] JIN H, XIANG G, ZOU D, et al. A guest-transparent file integrity monitoring method in virtualization environment[J]. Computers & Mathematics with Applications, 2010, 60 (2) : 256-266.
[10] PAYNE B D, DE A CARBONE M D P, LEE W. Secure and flexible monitoring of virtual machines[C]//ACSAC 2007:Proceedings of the Twenty-Third Annual Computer Security Applications Conference. Washington, DC:IEEE Computer Society, 2007:385-397.
[11] HABIB I. Virtualization with KVM[J]. Linux Journal, 2008 (166) .
[12] Intel. Intel 64 and IA-32 architectures software developer manuals[EB/OL].[2015-03-20]. https://software.intel.com/en-us/articles/intel-sdm.
[13] AMD. AMD64 architecture programmer’s manual volume 2:system programming[EB/OL].[2015-03-20]. http://developer.amd.com/resources/developer-guides-manuals/.
[14] 熊海泉, 刘志勇, 徐卫志, 等. VMM中Guest OS非陷入系统调用指令截获与识别[J]. 计算机研究与发展, 2014, 51 (10) : 2348-2359. ( XIONG H Q, LIU Z Y, XU W Z, et al. Interception and identification of guest OS non-trapping system call instruction within VMM[J]. Journal of Computer Research and Development, 2014, 51 (10) : 2348-2359. )