KVMSEC：Linux内核虚拟机的安全扩展

一，总结

  使用虚拟PC作为应用程序的数据中心服务器群集已经迅速增长。 本文介绍的这种体系结构的优点是可以提高全局系统的安全性。

  在本文中，我们提出了一个名为KvmSec的结构，它是Linux内核虚拟机的扩展。 目的是提高访客的安全性。  KvmSec保护客户端免受病毒和内核黑客工具的侵害。  KvmSec具有以下特征：对客户端是透明的，难以从受感染的虚拟机访问以上数据，并且无法分析第二个客户端上另一个第一客户端的数据； 它可以为客户端和主机提供安全的通信； 它可以部署在Linux主机和Linux客户端上。 这些功能可用于实施实时监视和管理系统。 此外，该设计优于上一代设计的安全解决方案，并且还构想了下一代安全的路线图。

  介绍

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

  完整性工具及其收集的数据通常放置在其监视的系统上。 这是个问题。 当系统受到恶意程序攻击时，它可能会篡改监视系统。  KvmSec被添加到虚拟化技术中，涵盖了整个系统的安全性。 虚拟访客可以受到其他边界的保护。 特别是，当系统监视程序（包括虚拟机监视器）可以提供受信任的计算库时，监视程序上就无法访问恶意程序。 这样，即使攻击者成功进入虚拟机，也无法删除攻击路径，也无法关闭外部安全系统。

  贡献

  本文解决了服务器加固期间客户端安全监视的问题。 我们提供的主要研究贡献是KvmSec系统结构，它可以保护和监视客户端。 当前的进展是允许主机实时控制客户端的未经授权的更改。 当客户端异常时，KvmSec可以检测并响应。 它是Linux内核虚拟机最小访问原则的扩展，并且监视系统本身是可见的。

  指南

  本文的其余部分安排如下：第3节：研究现有技术和相关工作，并提供有关我们工作的背景信息。 第4节：介绍KvmSec的要求和结构。 第5节：提供一些实现细节。 第6节：讨论KvmSec与先前结果之间的比较。 最后，第7节：结论。

  背景

  3.1虚拟化结构

  在下文中，我们分析了最相关的开源虚拟化结构Xen和KVM，以证明我们选择后者的原因。 完全虚拟化是一种使用CPU虚拟化的技术（AMD-V和Intel-VT支持的技术）。  CPU支持此技术功能，因此无需修改即可运行虚拟机中运行的操作系统，而无需知道是否存在更高的特权级别。 另一种虚拟化技术是半虚拟化。 它不需要CPU虚拟化技术支持，但通常需要重写客户机操作系统。

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

3.2相关工作

  下面我们简要解释用于入侵检测边界区域的集成监控器的问题。

  通过SHA摘要提供集成指标的集成管理结构。 加载后，将计算可执行文件，库和内核模块摘要，并将其存储在修改后的Linux内核本身中。 另外，集成管理结构的哈希值存储在与硬件连接的可信计算平台模块安全芯片的受保护平台配置寄存器中，以便远程方可以通过将存储的摘要与远程计算进行比较来确认系统集成 消化价值。 尽管摘要的性能影响很重要，并且未使用基于CPU的虚拟化支持，但集成管理结构提供了完整的工作参考结构。

  Xen虚拟机管理程序的主要功能不具备以下功能：Xen的sHype将虚拟机与强制访问控制隔离开来，并管理隐藏的通道。 修改Xen以保护用户的专用应用程序数据时，将从可信库中删除操作系统。 已移除。  XenFIT是一种实时文件系统集成工具，使用Xen虚拟机管理程序隔离各个部分，可以保护数据库和FIT系统免受攻击者的攻击。 实际上，FIT和数据库部署在单独的虚拟机上。 同样，XenRIM由DomU上的XenRIMU组成，该XenRIMU收集客户端信息，而Dom0上的Xenrimd则检查XenRIMU收集的信息并报告任何违反系统策略的行为。

  SecVisor使用基于CPU的虚拟化支持，以创建最小的虚拟机管理程序，以确保Linux内核代码的完整性并防止代码注入攻击。  SecVisor代码库非常小，它减小了可信计算库的大小，但不幸的是，它仅支持单个客户端。  SecVisor的结果不适用于在服务器上加强了操作系统安全性的情况。 而且，他仅成功保护了内核代码，而没有成功保护内核数据。

  Lares是使用虚拟化的活动体系结构，被放置在Xen虚拟机中，并且钩子安装在客户机上。 为了确保钩子不会被覆盖，Lares使用内存保护系统，该系统允许每个页面上的写权限通过其他指纹检查。  Lares的第一个原型似乎表现良好，但是，其监视使用挂钩程序，并且可以通过性能分析来检测。

  XenKimono是一个入侵检测系统，目标是通过从外部分析客户端内核的内部数据结构来检测恶意入侵（Tamberi的后续工作与此相关）。 所有XenKimono模块都在主机中，并对虚拟机的裸机内存进行分析以查看是否存在恶意程序（例如：rootkit）。 在高级内核数据结构中转换裸机的内存，从DOMU内核二进制文件中提取内核符号，并使用Linux内核故障转储库。 这样，XenKimono可以在原始内存中定位DOMU内核数据结构。

  四，KVMSEC的安全监控结构

  4.1威胁模型

  我们假定虚拟机管理程序和主机内核是受信任计算基础的一部分，但是虚拟机不是。 客户端运行时，将执行攻击并注入恶意软件。 客户端运行时，它可能成为病毒，代码注入，缓冲区溢出甚至所有恶意攻击的奴隶。 入侵者可能会利用这些缺陷来影响内核和应用程序，并远程使用这些缺陷以获取根权限。

  4.2要求和警告

  下面，基于上述威胁模型，我们描述了虚拟机安全系统的主要要求。 可以解决一些警告，以及解决它们的可能方法。

  要求：对于虚拟机，安全系统与入侵检测系统相关联。

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

RQ1要求1透明性是透明的：此系统对虚拟机的可见性应最小。 也就是说，潜在的入侵者无法检测到监视系统。

  RQ2需要2次免疫来抵抗来自Guset的攻击：主机和客户端应受到保护，免受来自受感染客户端的攻击； 此外，主机的特性不应受到影响。

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

  RQ4要求4动态响应：系统应检测到入侵客户端的尝试并采取适当的措施来抵抗入侵或漫游器攻击。

  警告：

  PR1需要从客户端到主机的通信通道。 主机读取有用的数据并从客户端提取信息，但是必须将其隐藏在客户端的用户空间中（请参阅RQ1）。

  PR2从客户端到主机的信号通道允许在客户端发生事件时通知主机，但是应尽可能隐藏这些主机（请参阅RQ1）。

  PR3为了确保一致性并保护信息泄漏，需要对通道进行一些访问控制。 这样，访问控制机制将不会对性能产生负面影响。

  五，KVMSEC的实施

  我们执行了KvmSec的原型，以确认我们的目标是可行的。  KvmSec体系结构由主机和客户端内核上的许多模块（可选）组成。 它们通过安全通道进行通信，以便主机可以获得正确的客户端状态。 监视系统的主要模块位于主机上，这使得客户端上的攻击者很难访问主机。 数据：（a）可以由客户端进程收集，或者（b）可以由主机上的进程专门收集和执行。

  特别是，（a）允许收集更准确和完整的客户数据，但易于检测。 客户端守护程序主要收集数据，这可以帮助主机减少计算负荷。 但是，在隐藏监视系统和减少主机计算机的计算负荷之间存在折衷。 对于（b）（无客户端组件），该技术从理论上减少了检测（请参阅RQ1），但仅允许有限的监视。 因此，KvmSec更喜欢（a）和（b）。

  值得注意的是，KvmSec中的每个虚拟机都使用其自己的私有内存区域与主机进行通信，该主机完全独立于其他虚拟机（请参阅RQ2）。

  KvmSec实现（参见图2）分为两个主要部分：主机和客户端。 两者具有相似的结构，即：1）内核守护程序管理和共享通信通道；  2）模块动态接收消息，对其进行分析并做出反应（生成响应）。

  在下面，我们主要列出我们采用的KvmSec解决方案的概述，以在满足之前的要求的同时满足我们面临的技术问题：

SL1主机-客户端通信系统在KVM中不可用，我们必须使用共享内存进行通信（请参阅PR1）。

  SL2在KVM中缺少主机和客户端信号通道，因此我们设计了一种使用共享内存的信号机制（请参阅PR2）。 我们也没有选择Xen的事件通道，因为以这种方式实现信号通道时，已经在客户端上的攻击者可以看到KvmSec。

  SL3在KVM中缺少共享内存访问控制，这使我们可以在共享内存中同步主机和客户端。 为了简化访问控制管理，每个KvmSec虚拟机都提供了自己的共享内存区域以与主机进行通信。 此外，对于两个单向通道中的每个通道，实现了一种简单的锁定机制，以便在消息传递时同步访问。

  在KVM中，与Xen不同，共享内存不是由管理程序直接管理，而是由主仿真过程Qemu-KVM管理。 使用共享内存的通信通道与RQ1相同。 实际上，在主机和客户端之间使用虚拟网络套接字的结果是可见的，并且在自愿的通信渠道中也是如此（如AIDE [1]中所述）。 此外，消息句柄包含在客户端内核模块中，以使其尽可能安全，与RQ2一致。 在主机上，消息句柄在Qemu-KVM共享内存管理模块中执行。  KVM共享内存（见图3）由两个数据缓存和两个锁组成，以保护相应的关键区域。

为了满足RQ4，KvmSec应该能够主动监视客户端上运行的关键进程。 当前，此功能尚未完全实现。 但是，KvmSec能够分阶段检查客户机上活动和活动守护程序的数量。 如果这些过程之一（异常）终止，则主机将进行适当的统计，包括收集数据以进行标识分析，甚至冻结客户端或可能重新启动客户端（使用可用的干净磁盘映像）。  KvmSec可以创建一个主机数据库，其中包含虚拟机上所选关键路径文件的计算摘要。 运行时守护程序可以重新计算哈希监视的文件。 如果发现不匹配，将执行如上所述的操作。

  各个模块中的通信协议（参见图4）相似。 主机和客户端之间的重要区别是：

1.共享内存的管理和分配：guest虚拟机上的共享内存是由内核模块分配和管理的，但是，主机上的共享内存必须已分配（在虚拟机中），并且其管理已分配给Qemu  -KVM过程。

  2.模块数量：在虚拟机中，我们只需要一对模块，因为共享内存管理已分配给内核。 在主机中，我们需要3个模块，将在下一部分中对其进行扩展。

  5.1 KvmSec主机

  主机部分由3个模块组成：KvmSecD，DM，Qemu-KVM。

 （1）KvmSecD：这是一个守护程序，可访问所有虚拟机地址空间。 此外，该模块还知道其他2个主机（Qemu-KVM和DM）的守护程序，因为这2个守护程序将其pids注册到KvmSecD。

  面向DM的通信通道：KvmSecD与DM之间的通信由组合字符设备（称为char_dev）管理，该字符设备由DM通过IOCTL接口和POSIX信号进行控制。 使用IOCTL接口扩展了字符设备的功能，并且通过允许一系列宏与内核模块进行交互，还定义了对这些设备的访问策略。

  在每个通信阶段，内核元素（即缓冲区）均由防锁定内核模块保护。  （为此，我们的代码使用以下原始元素：信号量（sem等待），互斥量（mux），原子变量（reg和qemu alive）。） 访问缓冲区是通过使用宏的进程（DM）完成的，因为关键区域已经受到保护。 这样，可以升级系统中的多个用户空间进程，因为它们通过这些宏访问缓冲区。

  （2）DM：DM是两个用户空间守护程序中的第一个，它由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（主机和VM）通信协议：虚拟机和主机之间的通信协议取决于对共享内存区域的同步访问。  Qemu使用cpu_physical_memory_rw函数允许写入虚拟机的内存。 主机-VM同步基于此功能构建。 通过这种方式，多路访问读写缓冲区被同步，受保护并且与操作系统无关。

5.2 KvmSec客户端

  KvmSec客户端包含2个模块：KvmSecDVM和DMVM

  （1）KvmSecDVM：这是一个Linux内核守护程序，用于管理虚拟机和主机之间的通信。 该守护程序有权访问内核内存。 该模块分配共享内存进行通信。 此外，我们分配了一个缓冲区来保存共享内存的物理地址。 通信协议与上述相同。

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

  讨论区

  KvmSec的目标是提供一个可能未被检测到的秘密系统，从而可以捕获对虚拟机完整性的侵犯。 与以前的系统相比，KvmSec提供的功能最重要：

  性能：我们已经对KvmSec和Kvm进行了基本性能测试。 特别是，我们测量了时间要求：使用标准配置（内核构建）执行标准2.6内核，将其源代码压缩为tarball（内核unbz2）。 该测试使用了运行Fedora 9 x86（主机和虚拟机）的Vaio便携式计算机，2GB内存，单核2.1Ghz处理器。 初步结果显示在表2中，该表显示KvmSec仅略高于Kvm要求。

透明：KvmSec的客户端和主机消息不受标准网络堆栈的控制（发生在主流完整性结构中，请参阅第3.2节）； 它们都是不可检测的（RQ1）； 与Xen的虚拟机管理程序不同，KvmSec仅依靠自己的内部通信协议（请参阅第5.1节）使其独立于所采用的虚拟机系统，此外，KvmSec中的每个虚拟机都有自己的共享内存区域，用于主机和虚拟机通信； 这样就可以独立管理每个通信通道，并且与其他通道（RQ2）无关。

  信号：由于主机与虚拟机之间没有明显的信号通道（RQ1），因此与其他系统（例如XenRim）相比，检测到KvmSec的可能性可能较小（请参阅第4节）。

  守护程序处理：KvmSec可以在主机和客户端之间共享监视任务。 在正常情况下，这将提供性能优势并提高监视质量。 公平交易使监视客户的模块更有可能检测到整个系统。  KvmSec结构中并不严格要求客户端模块。

  抗破坏性：请注意，内核检测系统位于主机上，这使系统很难受到破坏。 此外，管理主机与客户端之间的通信的模块位于客户端内核中（请参见第4节）（RQ2）。

  部署：KvmSec可以部署在任何最新的Linux内核中，而其他建议（例如XenKimono）则要求在主机上安装Xen虚拟化系统并在其上运行。 接下来，与基于Xen的解决方案相比，KvmSec支持更多的主机平台（请参阅第3.1节）（RQ3）。

  结论

  在本文中，我们提出了一种扩展Linux内核虚拟机的结构：kvmsec。 特别是，我们将KVM扩展为专注于安全性，并提供了用于对虚拟机进行实时完整性监视的解决方案（KvmSec）。 据我们所知，这是Linux KVM的第一个安全主题。 我们开发的KvmSec原型具有以下特征：对客户端透明（即使是遭到恶意黑客入侵的客户端）； 支持完全虚拟化，这将减少对客户端的检测； 它可以收集数据，并且要与客户端交互，其内核存储在受保护的主机上； 它提供了从系统管理程序到客户端的两种安全通信方法。 它可以部署在x86和x86_64机器上。

  为了进一步研究，我们努力减少入侵检测模块，将文件系统完整性工具添加到系统扩展模块，并完全添加上述KvmSec的功能。 仔细研究性能问题，并使用Windows家族中的虚拟机。