一、摘要

以虚拟化PC为应用的数据中心服务器群下降很快。本文介绍的这个构架，优点是降低全局系统安全。

在这篇论文中，我们提出一个结构叫：KvmSec，它是Linux内核虚拟机的扩充，目标是降低顾客机的安全。KvmSec能避免顾客机遭到病毒与内核黑客工具的功击。KvmSec有下边的特点：对顾客机透明，它很难从被攻陷的虚拟机访问里面的数据，也不能在第二台顾客机剖析其他第一台顾客机的数据；它能提供顾客机与主机的安全通讯；它既能被布署于Linux宿主机，也能被布署于Linux顾客机。对于执行实时监控和管理系统，这种特点起到杠杆作用。更进一步地说，本设计优于前人设计的安全解决方案，也设想了下一代安全的路线图。

二、介绍

虚拟化是一个老概念，如今是它的黄金年代。它被广泛使用在桌面PC、数据中心与服务器集群。到目前为止，最广泛被采用的x86虚拟化解决方案有：VMware、Xen、UserModeLinux、Qemu、KVM。近来几年虚拟化解决方案的可靠性也增强了，而且对虚拟机上安全服务与操作系统的功击是使人发怒的。恶意入侵者常常成功的功击系统并获得管理员权限。像木马与侧门程序才能被插入，重要或私有文件能被访问。为此，许多类型功击意味着改变文件系统。入侵保护工具一般检测文件更改，非常是那些文件的安全通道。

完整性工具与它搜集的数据一般一般放置在它所监控的系统上。这是一个问题，当一个系统被恶意程序功击，能够篡改监控系统。KvmSec被加入到虚拟化技术上，覆盖整个系统安全。虚拟顾客机能被额外的边界保护。特殊地，当一个系统监控程序（也包括VirtualMachineMonitor），能提供可信估算基，因而在监控系统上，使恶意程序不可达。这样虽然功击者成功的步入虚拟机，功击路径不可被删掉，外部安全系统不能被关掉。

贡献

这篇论文陈述在服务器加固时，顾客机安全监控的问题。我们所给与的主要研究贡献是KvmSec系统结构,它可以保护与监控顾客机。当前的进展是，实时容许主机控制顾客机未授权的变更。当顾客机异常时，KvmSec能探测与作出反应。它是LinuxKernelVirtualMachine最小化存取原则的扩充，但是监控系统自身可见。

指引

这篇论文其余的部份如下组织：第3节：督查现有的技术和相关工作，提供我们工作的背景信息。第4节：描述KvmSec的要求与结构。第5节：提供一些执行细节。第6节：讨论KvmSec和先前的结果的比较。最后，第7节：得出推论。

三、背景3.1虚拟化结构

在下边我们剖析最相关的开源虚拟化结构Xen和KVM，为了证明为何我们选择前者。全虚拟化是一个使用CPU虚拟化技术（AMD-V和Intel-VT支持的技术）。CPU支持这些技术特点，致使虚拟机中运行的操作系统不用更改，就可以运行，而不须要晓得更高特权级的存在。另外一种虚拟化技术是半虚拟化。它不须要CPU虚拟化技术的支持，但一般要求改写顾客机操作系统。

Xen，最被广泛采用的虚拟化解决方案，由Xenhypervisor(orVMM)，特权VM(Dom0)，当操作系统被运行时的普通VM(DomU)组成。Xen的特点：1）共享显存：虚拟机间通信通道；2）以太通道：虚拟机间的讯号通道；3）共享显存存取控制：存取控制矩阵，描述虚拟机可以访问的共享显存。Xen的驱动被定义在Dom0特权域中。所以其他域的I/O恳求由Dom0处理，hypervisor的职责是当有I/O操作恳求时从DomU转换到Dom0。

KVM，是新的主流Linux虚拟化解决方案，在2.6.20内核版本中加入内核。KVM的组成（见图1的执行模式）由一个hypervisor（Linux内核模块），经过更改的QEMU模拟器软体。KVM是一个标准的内核模块，作为使用标准的、可靠的、经常更新的Linux设备驱动的结果。一方面，这是为何KVM比Xen少受功击的一个诱因，Xen的驱动开发比标准Linux慢。另一方面，内核代码基比Xen大，潜在地包含更多的弱点和问题。Xen和KVM的比较在“表1”.KVM没有完全成熟，但比Xen有更好的方面，非常是广泛的硬件支持和降低的灵活性，（重新布署新的KVM版本不须要重新启动机器）。并且，更多的努力加入到KVM和Qemu的产品中。

3.2相关工作

下边我们简略地说明到集成监控器问题，它被使用于入侵检查边界区。

集成管理结构，提供通过SHA摘要进行集成性测度。当装载的时侯，可执行文件，库与内核模块摘要被估算与储存在被更改的Linux内核自身。据悉，集成管理结构的哈希被储存在附加在硬件上的可信估算平台模块安全芯片的受保护的平台配置寄存器中，这样远程方可以通过比较储存的摘要与远程估算的摘要值确认系统集成。其实摘要在性能上带来的影响很重要，但是基于CPU的虚拟化支持并未使用，集成管理结构提供一个完整的工作参考结构。

最主要的Xenhypervisor的杠杆作用没有以下能力：Xen的sHype隔绝虚拟机与强制访问控制，同时管理隐蔽通道，当更改Xen去保护用户的私有应用程序数据时linux查看硬件信息，也就将操作系统从可信基中移除。XenFIT是一个实时文件系统集成工具保护数据库和FIT系统，避免功击者使用Xenhypervisor隔离的部份。事实上，FIT和数据库被布署到分离的虚拟机上。同样，XenRIM由DomU上的XenRIMU构成，搜集顾客机的信息，但是Dom0上的Xenrimd检测XenRIMU搜集的信息，报告任何系统策略的违背。

SecVisor使用基于CPU的虚拟化支持，为了创建最小hypervisor保证Linux内核代码完整，避免代码注入功击。SecVisor代码基是十分小的，它减轻了可信估算基的大小，并且不幸的是只支持单顾客机。SecVisor的结果不适用于操作系统安全在服务器加固的场景。并且，他只是成功保护内核代码而不是内核数据。

Lares是一个活动的使用虚拟化的结构，被放置在Xen虚拟机，但是在顾客机上安装钩子程序。为了确保钩子程序不被覆盖，Lares使用显存保护系统，使每页写权限通过附加指纹检测。Lares第一个原型看上去执行挺好，但是linux虚拟机 主机，它的监控使用钩子程序，才能通过性能剖析被探测到。

XenKimono是一个入侵检查系统，目标是发觉恶意入侵，它通过从外边剖析顾客机内核内部数据结构（Tamberi后续的工作和此有关）。所有XenKimono模块在宿主机内，而且剖析虚拟机的裸显存，看是否有恶意程序（比如：rootkits）。在中级内核数据结构翻译裸虚拟机的显存，但是从DOMU内核二补码中抽取内核符号，但是使用LinuxKernelCrashDump库。这样，XenKimono才能在裸显存中定位DOMU内核数据结构。

四、KVMSEC一个安全监控结构4.1恐吓模型

我们假设hypervisor和宿主机内核是可信估算基的一部份，但是，虚拟机并不是。当顾客机运行时，功击被执行，恶意软件也会注入。当顾客机运行时，它可能成为病毒、代码注入、缓冲区溢出、甚至所有恶意功击的奴隶。入侵者可能使用缺陷去影响内核与应用程序，并远程使用这种缺陷，企图获取root权限。

4.2要求与警告

在下边，基于前面的恐吓模型，我们描述对于虚拟机安全系统的主要要求，一些警告能被解决，也是能解决它们的可能方法。

Requirements要求：对于虚拟机，一个安全系统是和入侵测量系统关联的。

一个安全系统必须满足以下要求：

RQ1要求1Transparency透明：此系统对于虚拟机因该是最小化可见的；也就是说，潜在的入侵者不能探测到监控系统。

RQ2要求2ImmunitytoattacksfromtheGuset免疫从顾客机的功击：宿主机和顾客机应当被保护，避免从被侵入的顾客机功击；并且，宿主机的特点不应被影响。

RQ3要求3Deployability可布署性：系统应可以被布署到主流硬件上。

RQ4要求4Dynamicreaction动态反应：系统应检查入侵顾客机的企图linux虚拟机 主机，并采取合适的反应谴责入侵或谴责僵尸机的功击。

Caveats警告:

PR1一个从顾客机到宿主机的通信通道被要求，宿主机去读有用的数据，并从顾客机抽取信息，并且它必须被隐藏在顾客机的用户空间（参考RQ1）。

PR2一个从顾客机到宿主机的讯号通道容许宿主机在顾客机发生风波时被提示，然而这种应当被尽可能地隐藏（参考RQ1）。

PR3一些在通道上的存取控制被要求，为了去保证一致性，同时保护信息泄漏；这样，一个存取控制机制不会有对性能的负面影响。

五、KVMSEC执行

我们执行KvmSec的原型，去否认我们的目标是可行的。KvmSec构架是由好多在宿主机和顾客机内核上的模块（可选）构成，它们通信通过安全通道，使宿主机得到正确的顾客机状态。检测系统的主模块定位于宿主机上，致使在顾客机上的功击者很难访问宿主机。数据：（a）能被顾客机进程搜集或（b）能被宿主机上的进程独占的搜集并执行。

非常地，（a）准许搜集更确切的与完整的顾客机数据，并且容易被测量。一个顾客机守护进程主要搜集数据，这可以帮助宿主机降低估算负载。但是，在监控系统的隐蔽性和降低宿主机估算负载有折中。对于（b）（没有顾客机组件）这个技术理论上降低被探测（看RQ1），并且仅容许有限的监控。由于这个缘由，KvmSec更喜欢（a），而（b）也被支持。

值得注意的是，在KvmSec中每位虚拟机使用它自己私有的显存区与宿主机通讯，它完全独立于其他虚拟机（参考RQ2）。

KvmSec执行（看图2）被分为2个主要部份：宿主机和顾客机。二者有相像的结构，它是：1）一个内核守护进程管理与共享通讯通道；2）一个模块动态收消息，剖析它们并反应（生成响应）。

在下边我们主要列举我们采纳的对于KvmSec的解决方案的大纲，响应我们面对的技术问题，同时遵照原先的要求：

SL1宿主机顾客机通讯系统在KVM中不可用，我们不得不使用共享显存的方法使之通讯（看PR1）。

SL2在KVM中没有宿主机和顾客机讯号通道引起我们设计使用共享显存的讯号机制（看PR2）。我们也不选择Xen的风波通道，由于那样实现讯号通道时，致使KvmSec对于早已在顾客机的功击者能看见。

SL3在KVM中缺少共享显存的存取控制使我们在共享显存中同步宿主机与顾客机。为了简化存取控制管理，每位KvmSec虚拟机提供它自己的共享显存区为和宿主机通信。并且，对于两个双向通道的每一个，简单的锁定机制被执行，为了在消息通行时去同步存取。

在KVM中，不像Xen，共享显存不被hypervisor直接管理，而是被主模拟进程Qemu-KVM管理。使用共享显存的通讯通道和RQ1是一致的。实际上，在宿主机和顾客机间使用一个虚拟网路套接字的结果是可见的并在志愿通讯通道中（正像发生在AIDE[1]中）。并且，消息句柄被包含在顾客机内核模块中为了使它尽可能的安全，和RQ2一致。在宿主机上，消息句柄是在Qemu-KVM共享显存管理模块中执行。KVM共享显存（看图3）由2个数据缓存和2个锁组成，为保护相应的关键区。

去满足RQ4KvmSec应当能活动地监控运行在顾客机上的关键进程。目前，这些功能没有完全实现；但是，KvmSec能阶段地检测顾客机上的存在的和活跃的守护进程数目。若果这种进程其中一个（非正常）中止，宿主机将采取合适的统计，包括搜集数据为鉴别剖析，甚至冻结顾客机或可能重启动它（使用可用的干净的c盘镜像）。KvmSec能创建一个宿主机方的数据库，包含虚拟机上选取的关键路径文件的估算的概要。一个运行时守护进程能重估算hash为监控的文件。倘若不匹配发觉，像前面所描述的举措将被执行。

在各类模块中的通讯合同（看图4）是相像的。宿主机和顾客机明显的区别是：

1.管理与分配共享显存：在顾客机上共享显存被分配与通过内核模块管理，但是在宿主机，共享显存必须早已被分配（在虚拟机中），但是它的管理被委派给Qemu-KVM进程。

2.模块数目：在虚拟机中，我们只须要一对模块，由于共享显存管理被委派给内核，在宿主机中，我们须要3个模块，将在下一节中扩充。

5.1KvmSec宿主机

宿主机部份由3个模块组成：KvmSecD,DM,Qemu-KVM.

(1)KvmSecD:它是守护进程而且访问所有的虚拟机地址空间。据悉，这个模块晓得其他2个宿主机的守护进程（Qemu-KVM和DM），由于那2个守护进程注册它们的pid到KvmSecD.

通信通道朝向DM：KvmSecD和DM之间的通讯由结合的字符设备（叫char_dev）所管理,由DM通过IOCTL插口和POSIX讯号控制。字符设备的能力使用IOCTL插口扩充，通过容许一系列宏与内核模块交互，还定义到这种设备的访问策略。

在每位通信阶段，内核元素（也就是buffers）被内核模块锁门而保护。（为了这个目的我们的代码使用下边的原始元素：semaphores(semwait),mutexes(mux),atomicvariables(regandqemualive).）。访问buffer通过一个进程（DM）使用宏完成linux shell，由于关键区域早已被保护。在这些形式下，系统超过一个用户空间进程都可以升级，由于它们访问buffer通过这种宏。

(2)DM：DM是2个用户空间守护进程的第一个，由2个线程组成：

1.DM-它是主要的线程，管理：a）DM和KvmSecD，DM和Qemu间的通信；b）贯串Qemu-KVM从共享显存创建与接收消息；c）注册DM的pid到KvmSecD中。

2.WATCHER-它是第二个线程，管理：a）Qemu-KVM的启动；b）注册Qemu-KVM的pid到KvmSecD中；c）非正常中止Qemu-KVM；

与Qemu的通讯通道：既然DM和Qemu进程在用户空间执行，我们能使用任何LinuxSystemVIPC工具为进程间通讯。特殊地，我们使用PIPE（或FIFO）

(3)Qemu-KVM：Qemu-KVM是更改的Qemu，它与内核模块KVM合并通讯机制。

Qemu与VM（hostandVM）的通讯合同:在虚拟机和宿主机间的通讯合同依赖同步访问共享显存区。Qemu使用cpu_physical_memory_rw函数容许写虚拟机的显存。Host-VM同步构建于此函数。在这些方法下，多存取读写缓冲是同步的，受保护的，操作系统独立的。

5.2KvmSec顾客机

KvmSec顾客机由2个模块组成：KvmSecDVM和DMVM

(1)KvmSecDVM：它是Linux内核守护进程，管理虚拟机和宿主机的通讯。这个守护进程对内核显存有访问权。这个模块分配通信用共享显存。并且，我们分配一个buffer容纳共享显存的化学地址。通讯合同同上。

(2)DMVM：它是一个守护进程，处理监控，剖析，创建响应的任务。这个模块管理共享显存的消息。像在宿主机一样，使用字符设备（char_dev）作为它与KvmSecDVM的通讯通道。通讯合同也类似DM和KvmSecD。这个模块检测关键路径文件存取，并更正。这个模块将来的执行将为其他集成检测插件提供空间。

六、讨论

KvmSec的目标是提供潜在的未被察觉的，不被暗中破坏的系统，致使可以捕捉虚拟机完整性的违背。由KvmSec提供的特点与先前的系统想比最明显的有如下内容：

性能：我们早已执行基本性能测试对比KvmSec与Kvm。非常地，我们测度了时间要求：执行标准2.6内核使用标准配置（Kernelbuild），压缩它的源代码到tarball(Kernelunbz2).测试使用Vaio便携式计算机，2GB显存，单核2.1Ghz处理器，运行Fedora9x86（宿主机和虚拟机）。初步结果在表2，显示KvmSec仅比Kvm要求初一点。

透明：KvmSec的顾客机与宿主机消息并不通过标准网路栈控制（发生在主流完整性结构，看3.2节）；所有它们是不可测量的（RQ1）；KvmSec仅依赖它自己的内部通讯合同（看5.1节），使它独立于所采纳的虚拟机系统，不像Xen的hypervisor。并且，KvmSec中每位虚拟机有它自己的共享显存区可以进行宿主机和虚拟机通讯；这使每位通讯通道独立管理，并和其他通道不相关（RQ2）。

讯号：KvmSec潜在的比其他系统（比如XenRim）多于被探测，由于在宿主机和虚拟机间没有显著的讯号通道（RQ1）（看4节）。

守护进程处理：KvmSec可以在宿主机和顾客机间共享监控任务。这将提供性能优势，但是降低在一般情况下监控的质量。公正的交易使监控顾客机的模块让整个系统更可能遭到探测。在KvmSec结构中顾客机模块并不严格要求。

抵抗妥协：注意内核探测系统在宿主机上，这使系统很难被打入。并且，管理宿主机和顾客机通讯的模块在顾客机内核中（看4节）（RQ2）。

布署：KvmSec能被布署在任何最新的Linux内核中，而其他的建议（比如XenKimono）要求Xen虚拟化系统被安装与运行在宿主机上。接着，KvmSec所支持的宿主机平台数量比基于Xen解决方案多（看3.1节）（RQ3）。

七、结论

在这篇论文中，我们提出一个扩充Linux内核虚拟机的结构：kvmsec。非常地，我们扩充KVM聚焦于安全，为虚拟机的实时完整性监控提供一个解决方案（KvmSec）。据我们了解，这是第一个针对LinuxKVM的安全课题。我们所开发的KvmSec原型有如下特点：对于顾客机是透明的（甚至是早已被恶意侵入的顾客机）；支持全虚拟化，这将使顾客机方降低被探测到；它能搜集数据并与顾客机交互，它的内核保存在受保护的宿主机上；它提供hypervisor到顾客机的两种安全通讯方法；它能被布署到x86和x86_64的机器上。

对于进一步的研究方向，我们努力去降低入侵检查模块，并将文件系统完整性工具加入到系统扩充模块，完全加入前面所述KvmSec的特点。进一步地深入研究性能问题和使用Windows家族的虚拟机。

本文原创地址：https://www.linuxprobe.com/lnhxnhjjfadj.html编辑：刘遄，审核员：暂无