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

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

一、摘要

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

在这篇论文中，我们提出一个结构叫：KvmSec，它是Linux内核虚拟机的扩展，目标是增加客户机的安全。KvmSec能防止客户机受到病毒与内核黑客工具的攻击。KvmSec有下面的特征：对客户机透明，它很难从被攻破的虚拟机访问上面的数据，也不能在第二台客户机分析其他第一台客户机的数据；它能提供客户机与主机的安全通信；它既能被部署于Linux宿主机，也能被部署于Linux客户机。对于执行实时监控和管理系统，这些特征起到杠杆作用。更进一步地说，本设计优于前人设计的安全解决方案，也构想了下一代安全的路线图。

二、介绍

虚拟化是一个老概念，现在是它的黄金年代。它被广泛使用在桌面PC、数据中心与服务器集群。到目前为止，最广泛被采用的x86虚拟化解决方案有：VMware、Xen、User Mode Linux、Qemu、KVM。最近几年虚拟化解决方案的可靠性也提高了，但是对虚拟机上安全服务与操作系统的攻击是使人恼怒的。恶意入侵者经常成功的攻击系统并获得管理员权限。像木马与后门程序能够被插入，重要或私有文件能被访问。因此，许多类型攻击意味着改变文件系统。入侵保护工具通常检查文件修改，特别是这些文件的安全通道。

完整性工具与它收集的数据通常通常放置在它所监控的系统上。这是一个问题，当一个系统被恶意程序攻击，就能篡改监控系统。KvmSec被加入到虚拟化技术上，覆盖整个系统安全。虚拟客户机能被额外的边界保护。特殊地，当一个系统监控程序（也包括Virtual Machine Monitor），能提供可信计算基，因此在监控系统上，使恶意程序不可达。这样即使攻击者成功的进入虚拟机，攻击路径不可被删除，外部安全系统不能被关闭。

贡献

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

指引

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

三、背景

3.1 虚拟化结构

在下面我们分析最相关的开源虚拟化结构Xen和KVM，为了证明为什么我们选择后者。全虚拟化是一个使用CPU虚拟化技术（AMD-V和Intel-VT支持的技术）。CPU支持这种技术特征，使得虚拟机中运行的操作系统不用修改，就可以运行，而不需要知道更高特权级的存在。另外一种虚拟化技术是半虚拟化。它不需要CPU虚拟化技术的支持，但通常要求改写客户机操作系统。

Xen，最被广泛采用的虚拟化解决方案，由Xen hypervisor (or VMM)，特权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的虚拟化支持并未使用，集成管理结构提供一个完整的工作参考结构。

最主要的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问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注亿速云行业资讯频道了解更多相关知识。