如何解析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問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。