如何解析Linux内核虚拟机的安全扩展KVMSEC

如何分析Linux内核虚拟机的安全扩展KVMSEC，针对这个问题，本文详细介绍了相应的分析和解答，希望能帮助更多想要解决这个问题的小伙伴找到更简单更容易的方法。

一、摘要

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

本文提出了一种称为KvmSec的结构，它是Linux内核虚拟机的扩展，其目标是提高客户端的安全性。KvmSec可以防止客户端受到病毒和内核黑客工具的攻击。KvmSec具有以下特点：对客户端是透明的，很难从被黑客入侵的虚拟机中访问数据，无法分析第二客户端中其他第一客户端的数据；它可以提供客户端和主机之间的安全通信；它可以部署在Linux主机和Linux客户端中。这些特性为实时监控和管理系统的实施提供了杠杆作用。而且，这种设计优于前人设计的安全解决方案，也构思了下一代安全的路线图。

二、介绍

虚拟化是一个古老的概念，现在是它的黄金时代。它广泛应用于台式电脑、数据中心和服务器集群。到目前为止，最广泛采用的x86虚拟化解决方案是VMware、Xen、用户模式Linux、Qemu和KVM。近年来，虚拟化解决方案的可靠性也有所提高，但对虚拟机上的安全服务和操作系统的攻击令人恼火。恶意入侵者通常会成功攻击系统并获得管理员权限。可以插入木马和后门程序，可以访问重要或私人文件。因此，许多类型的攻击意味着改变文件系统。入侵防护工具通常会检查文件的修改，尤其是这些文件的安全通道。

完整性工具及其收集的数据通常放在它监控的系统上。这是一个问题。当系统受到恶意程序攻击时，它可以篡改监控系统。KvmSec加入虚拟化技术，覆盖整个系统安全。虚拟客户端可以受到额外边界的保护。特别是，当系统监控程序(包括虚拟机监控程序)能够提供可信的计算基础时，监控系统中就不会有恶意程序。即使攻击者成功进入虚拟机，攻击路径也无法删除，外部安全系统也无法关闭。

贡献

本文阐述了服务器硬化过程中的客户端安全监控问题。我们的主要研究贡献是KvmSec系统架构，可以保护和监控客户端。目前，它允许主机实时控制客户端的未授权更改。当客户端出现异常时，KvmSec可以检测并做出反应。它是Linux内核虚拟机最小访问原则的扩展，监控系统本身是可见的。

00-1010本文其余部分组织如下：第三节：调查现有技术和相关工作，并提供我们工作的背景信息。第4节：描述KvmSec的要求和结构。第5部分：提供一些实现细节。第6节：讨论千伏安毫秒和以前结果的比较。最后，第七部分：得出结论。

00-1010

指引

在下面，我们分析了最相关的开源虚拟化结构Xen和KVM，以证明我们为什么选择后者。全虚拟化是一种使用CPU的虚拟化技术(由AMD-V和英特尔-VT支持)。CPU支持这一技术特性，使得虚拟机中运行的操作系统无需修改即可运行，无需知道更高权限级别的存在。另一种虚拟化技术是半虚拟化。它不需要CPU虚拟化技术的支持，但通常需要重写来宾操作系统。

Xen是应用最广泛的虚拟化解决方案，在操作系统运行时，由Xen虚拟机管理程序(或VMM)、特权虚拟机(Dom0)和普通虚拟机(DomU)组成。Xen特点：1)共享内存：虚拟机之间的通信通道；2)以太网通道：虚拟机之间的信号通道；3)共享内存访问控制：访问控制矩阵描述了虚拟机可以访问的共享内存。Xen的驱动程序是在Dom0特权域中定义的。因此，其他域的I/O请求由Dom0处理，当有I/O操作请求时，虚拟机管理程序的职责是从DomU切换到Dom0。

KVM是一种新的主流Linux虚拟化解决方案，它将内核添加到了2.6.20内核版本中。KVM(见图1的执行模式)由一个管理程序(Linux内核模块)、修改后的QEMU模拟器软件组成。KVM是一个标准的内核模块，是使用标准、可靠和经常更新的Linux设备驱动程序的结果。一方面，这是KVM比Xen受攻击少的一个原因，Xen的驱动开发比标准Linux慢。另一方面，内核代码库比Xen大，这可能包含更多的弱点和问题。与表1中的Xen KVM相比，KVM还没有完全成熟，但它比Xen有更好的方面，尤其是广泛的硬件支持和增加的灵活性(不需要重启机器来重新部署新的KVM版本)。此外，应更加努力加入KVM和Qemu产品。

00-1010接下来，我们简单说明一下集成监控器的问题，它用于入侵检测边界区域。

综合管理结构，通过SHA提供总结

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

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

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

Lares 是一个活动的使用虚拟化的结构，被放置在Xen虚拟机，并且在客户机上安装钩子程序。为了确保钩子程序不被覆盖，Lares 使用内存保护系统，使每页写权限通过附加指纹检查。Lares 第一个原型看起来执行很好，然而，它的监控使用钩子程序，能够通过性能分析被侦测到。

XenKimono 是一个入侵检测系统，目标是发现恶意入侵，它通过从外面分析客户机内核内部数据结构（Tamberi后续的工作和此有关）。所有 XenKimono 模块在宿主机内，并且分析虚拟机的裸内存，看是否有恶意程序（例如：rootkits）。在高级内核数据结构翻译裸虚拟机的内存，并且从DOMU内核二进制中抽取内核符号，并且使用Linux Kernel Crash Dump库。这样，XenKimono 就能在裸内存中定位DOMU 内核数据结构。

四、KVMSEC一个安全监控结构

4.1 威胁模型

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

4.2 要求与警告

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

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

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

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

RQ2 要求2 Immunity to attacks from the Guset 免疫从客户机的攻击：宿主机和客户机应该被保护，防止从被侵入的客户机攻击；而且，宿主机的特征不应被影响。

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

RQ4 要求4 Dynamic reaction 动态反应：系统应检测入侵客户机的试图，并采取合适的反应抵制入侵或抵制僵尸机的攻击。

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个锁组成，为保护相应的关键区。

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

在各种模块中的通信协议（看图4）是相似的。宿主机和客户机显著的区别是：

1.管理与分配共享内存：在客户机上共享内存被分配与通过内核模块管理，然而在宿主机，共享内存必须已经被分配（在虚拟机中），并且它的管理被指派给Qemu-KVM 进程。

2.模块数量：在虚拟机中，我们只需要一对模块，因为共享内存管理被指派给内核，在宿主机中，我们需要3个模块，将在下一节中扩展。

5.1 KvmSec 宿主机

宿主机部分由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 (sem wait), mutexes (mux ), atomic variables (reg and qemu alive).）。访问buffer通过一个进程（DM）使用宏完成，因为关键区域已经被保护。在这种方式下，系统超过一个用户空间进程都可以升级，因为它们访问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进程在用户空间执行，我们能使用任何Linux System V IPC 工具为进程间通信。特殊地，我们使用PIPE（或FIFO）

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

Qemu与VM（host and VM）的通信协议:在虚拟机和宿主机间的通信协议依赖同步访问共享内存区。Qemu使用cpu_physical_memory_rw 函数允许写虚拟机的内存。Host-VM同步建立于此函数。在这种方式下，多存取读写缓冲是同步的，受保护的，操作系统独立的。

5.2 KvmSec 客户机

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

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

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

六、讨论

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

性能：我们已经执行基本性能测试对比KvmSec与Kvm。特别地，我们度量了时间要求：执行标准2.6内核使用标准配置（Kernel build），压缩它的源代码到tarball(Kernel unbz2).测试使用Vaio便携式计算机，2GB内存，单核2.1Ghz处理器，运行Fedora 9 x86（宿主机和虚拟机）。初步结果在表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）。据我们了解，这是第一个针对Linux KVM的安全课题。我们所开发的KvmSec 原型有如下特征：对于客户机是透明的（甚至是已经被恶意侵入的客户机）；支持全虚拟化，这将使客户机方减少被侦测到；它能收集数据并与客户机交互，它的内核保存在受保护的宿主机上；它提供hypervisor到客户机的两种安全通信方式；它能被部署到x86和x86_64的机器上。

关于如何解析Linux内核虚拟机的安全扩展KVMSEC问题的解答就分享到这里了，希望