云計算客戶虛擬機間的安全機制研究與實現

喬 然,胡 俊,榮 星

(北京工業大學計算機學院,北京 100124)

1 概述

作為一種全新的計算與服務模式,云計算技術在近年來得到了快速發展,并在社會生活中扮演著越來越重要的角色。然而云安全事故的頻發嚴重制約云計算產業的發展壯大,凸顯了云計算安全問題的重要性[1]。

云計算面臨的安全風險是與其自身的技術特點和服務模式緊密關聯的。與傳統的網絡或集群應用模式相比,虛擬化技術是云計算最突出的特點之一。虛擬化共享技術的引入,在提高資源利用效率的同時,由于虛擬機環境的動態性等特點以及技術漏洞所帶來的相對于物理環境的弱安全性,為虛擬化環境的安全留下了隱患。

此外,云計算的另外一個特點——開放性同樣為云計算安全帶來了挑戰。開放性主要體現在服務對用戶的開放性和內部接口對外調用的開放性。開放性下身份驗證機制相對薄弱,這就使得惡意用戶可以通過合法的途徑進入云計算環境并進行攻擊以竊取需要的信息,良性的云計算環境也可能被非法用戶用于不正當用途。其中,虛擬機系統作為云計算的基礎設施又會成為這些攻擊的一個主要目標。

鑒于以上事實,如何建立有效的虛擬機安全機制就成為了云計算虛擬化安全研究的一個重要課題。然而,之前針對虛擬化安全的研究工作大多是針對單機虛擬化環境,難以適應云計算場景的要求。本文根據云計算環境的要求,設計集中管理、分布式實施的云計算強制訪問控制,以及基于云計算資源控制的安全隔離機制,來保護客戶虛擬機的安全。

2 問題分析及相關研究

云計算虛擬化技術與傳統虛擬化最大的不同就是開放性帶來的多租戶共享計算資源,整個虛擬化平臺或客戶虛擬機受到惡意用戶從內部攻擊的可能性就會大幅提高。目前,云計算虛擬化面臨的主要安全威脅有虛擬機逃逸及隱通道信息泄露等[2-3]。

在傳統虛擬化技術中,針對虛擬機逃逸大多采用監控的方式來發現并阻止危險的發生。監控機制的一種思路通過虛擬機環境所提供的Hypervisor層從客戶虛擬機所處環境之外對其進行監控。這類機制可以有效地保護安全部件免遭篡改,同時這一方式對監控環境的影響較小,方便透明實現,在系統的兼容性上也有優勢。但這種方式會存在語義斷層問題。基于上述思路實現的客戶虛擬機保護機制主要有：Antfarm[4],sHype[5],XenAccess[6],VMWatcher[7]等。

然而云計算與傳統單機虛擬化環境架構的不同,控制權由Hypervisor 向控制節點Controller 轉移。傳統的虛擬機監控機制設計在計算節點Hypervisor 中,難以有效與云控制節點上虛擬機管理控制流程銜接,會出現安全鏈斷裂而無法保證虛擬機整個生命周期的安全,并不能很好地在云計算場景中發揮作用。新的云計算虛擬機監控機制應是一種集中管理,分布式實施的監控機制。在控制節點增加對計算節點監控機制的管理和配置,并且介入虛擬機創建流程,對虛擬機整個生命周期提供保護,而訪問控制的具體執行仍在計算節點上。

同樣,對于隱通道導致的信息泄露的問題,傳統虛擬化環境由于虛擬機不可避免地共享同一物理平臺,此類問題難以得到很好的解決。在云計算這一定位于商用的服務模式中,通過這一方式嘗試竊取其他用戶信息的情況大多存在于利益相關或有利益沖突的用戶間。并且此類用戶大多會意識到彼此的存在,這也為解決這一問題提供了突破口。可以考慮利用云計算多計算節點架構,通過控制計算節點與虛擬機間的關系進行虛擬機隔離,來阻斷信息流進而克服隱通道問題。

3 系統設計

本文采用了集中管理、分布式執行的云計算訪問控制機制,與基于云計算資源控制的隔離機制相結合,來保證云計算虛擬化平臺中客戶虛擬機的安全。

3.1 總體框架

系統主要由2 個部分功能組成：(1)集中管理、分布式實施的訪問控制功能；(2)基于云資源控制的隔離功能。2 個安全功能由統一的安全管理模塊進行配置管理并提供輔助功能。整個系統劃分為3 個部分：安全管理,訪問控制機制及隔離機制。系統架構如圖1 所示。

圖1 系統總體架構設計

本文的訪問控制機制基于STE 模型,執行在計算節點虛擬化層,直接監控虛擬機對虛擬資源的訪問。但對訪問控制的管理工作存在于云管理節點,這樣就可以有更加全面完整的視角監控虛擬機在云中創建流程,從而可以在虛擬機生命周期開始就配置訪問控制機制對其進行保護。這一機制的工作原理是：安全管理模塊會在虛擬機創建時調用訪問控制模塊,為目標虛擬機及虛擬資源添加標簽。在Hypervisor 中虛擬機對虛擬資源的訪問操作處理中已加入鉤子函數,每當虛擬機需要對虛擬資源進行訪問時,鉤子函數會截獲這一訪問請求,并判斷虛擬機是否具有訪問權限。本文中訪問控制機制的目的是發現惡意用戶行為,實現對虛擬資源的保護。本文訪問控制解決了將一般虛擬機監控機制運用在云環境中時監控機制運行在計算節點時與控制節點間的信息斷層問題。

基于云資源控制的隔離機制實現了中國墻模型,工作在云控制節點上,通過控制虛擬機啟動過程的基礎設施資源(即計算節點)分配來隔離虛擬機,而非對虛擬機的直接保護,如圖1 虛線部分所示。基于云計算資源控制方式的隔離機制就是在虛擬機創建或遷移時,控制計算節點與虛擬機間的關系,根據用戶提供的可能會與自己存在利益關系的其他用戶信息,將特定的計算節點分配給虛擬機,使虛擬機運行在沒有其他利益相關用戶虛擬機的計算節點上,從而避免信息泄露。該機制從虛擬機創建通過介入虛擬機的創建和遷移過程,將利益相關用戶的虛擬機建立在不同的計算節點上進行隔離,目的是杜絕隱通道帶來的非法信息流動。

這2 種安全機制工作在云計算不同的層次,訪問控制機制主要對客戶虛擬機資源提供運行時的保護,而隔離機制提供一種啟動前的預保護來解決隱通道問題,相互配合對客戶虛擬機進行保護。從虛擬機創建流程開始,安全機制會對整個虛擬機的生命周期進行保護。并由統一的安全管理模塊進行安全數據維護、安全策略配置等管理及輔助工作,使得2 種安全機制可以有效地協同運行在云計算環境中。

3.2 安全管理模塊設計

安全管理模塊運行在云控制節點上,負責對本文中的訪問控制機制與隔離機制進行統一管理及輔助功能,包括維護云平臺安全策略、用戶標簽相關等數據,管理訪問控制與隔離機制等。

3.2.1 標簽設計及安全策略

用戶標記及安全策略是本文安全機制工作的基礎,文中的2 種安全機制的正常工作都依賴于安全用戶標記,而這也正是本文將隔離機制與訪問控制機制相結合的切入點。本文提出了自己的安全標記設計及生成方法,使其能夠同時滿足STE 與中國墻模型的要求。

前文提到本文中的訪問控制基于STE 模型,而隔離機制基于中國墻模型。STE 模型是TE 模型[8]的簡化模型,其思想是將系統中的主體被劃分成若干不同的域,定義不同的域標簽賦予每個主體及每個客體。STE 模型訪問控制的執行方法就是根據主體和客體的標簽是否相同進行訪問行為控制。而中國墻策略模型是一種經典的隔離機制模型,用于避免利害相關的信息進入同一個控制域中。在中國墻模型中,實現一個運行態排除規則,這一規則定義一組互斥的負載類型標簽,即一個沖突集；任意時刻,在一個Hypervisor 平臺上只允許加載沖突集一種標簽的負載[9]。本文就是將STE 的標簽與中國墻的標簽進行整合,使用同一安全標記同時支持2 種安全機制。

在用戶標簽的設計上,考慮到云計算不僅會存在個人用戶,還需要同時滿足組織機構用戶的安全要求。云計算中一些組織機構希望能夠與和自己有利益關系的其他組織的虛擬機進行隔離,但不清楚對方組織內部的結構,此時就需要進行組織間的隔離。本文設計了二級用戶標簽作為一個用戶的唯一標志,其形式為(組織標簽.個人標簽)。這樣設計既可以滿足云計算從組織角度進行隔離的要求,又能將用戶標簽精確到每一個用戶可以為細粒度的訪問控制提供基礎。

標簽的生成方法可以是直接對組織名和用戶名的直接引用也可采用對用戶名和組織名計算摘要值作為標簽的方式,例如對用戶名和組織名稱進行MD5 運算作為對應的用戶和組織標記,這樣可以使得用戶標簽具有唯一性。用戶標簽在用戶向云平臺注冊時生成,從用戶虛擬機建立起就對虛擬機及屬于該虛擬機的資源進行標記,對客戶虛擬機整個生命周期進行保護。

設計了用戶標簽后,還需要對應的安全策略來指導安全機制的執行。由于統一了安全標簽,同樣需要設計統一的云平臺安全策略。訪問控制的STE策略相對簡單,只需要告知計算節點所有用戶標簽就可以執行訪問控制。而中國墻策略定義了一組沖突集,沖突集信息是執行隔離控制的根本依據。在本文場景下,沖突集信息應是用戶提出需要與自己虛擬機進行隔離的用戶名稱集合,反映自己的安全需求。每個云用戶應提出自己的沖突集,并由安全管理節點將所有用戶的需求整合成統一安全策略并部署到云平臺中。

3.2.2 安全管理模塊設計

安全管理模塊的主要工作有4 個方面：(1)管理云用戶標簽；(2)管理云平臺安全策略；(3)向新建虛擬機添加標簽開始訪問控制保護；(4)維護云平臺各計算節點虛擬機運行情況。在設計上,向計算節點發出虛擬機及資源標簽添加命令的功能被放在管理模塊,彌補了前文描述過的從計算節點進行管理會導致的安全鏈斷裂問題,管理模塊有更好的視角監控虛擬機啟動過程及用戶信息。此外,安全管理模塊還需要維護一個表來記錄當前云計算所有計算節點運行了哪些虛擬機以及這些虛擬機的標簽,為隔離機制提供支持。該模塊需要實現的具體功能主要有：

(1) 向上層提供接口接收經中間件層發來的用戶注冊信息及沖突集要求；

(2) 根據用戶的信息進行運算,得到兩級用戶安全標記,并記錄；

(3) 整合所有用戶標簽及沖突集要求,形成安全策略文檔；

(4) 將安全策略文件部署給訪問控制及隔離模塊；

(5) 向虛擬機啟動過程提供各種信息支持；

(6) 與虛擬機建立命令協調,調用計算節點訪問控制功能添加主客體標簽；

(7) 維護云平臺虛擬機運行信息。

基于以上分析,本文安全管理模塊需要在虛擬機生命周期的3 個過程中介入進行安全配置,使得訪問控制機制和隔離機制可以對云計算中的虛擬機進行保護。得到該模塊的工作流程如圖2 所示。

圖2 安全管理模塊工作流程

3.3 訪問控制機制設計

訪問控制機制的具體執行在計算節點上,由2 個功能模塊組成。

3.3.1 訪問控制配置模塊

訪問控制配置模塊工作在各個計算節點的宿主操作系統Dom0 中,負責與云控制節點安全管理模塊通信,接收命令完成對本計算節點的訪問控制執行機制的配置及管理。該模塊是將在云計算環境中實現訪問控制的關鍵部件之一,起到了紐帶作用,訪問控制配置模塊具體需要完成的工作有：(1)接收控制節點安全管理模塊發送的命令及數據,包括安全策略數據及更新命令、用戶虛擬機標簽的添加等；(2)當通信模塊接收到這些命令后,需要對這些數據進行處理并調用接口部署到Hypervisor；(3)命令執行完成后,通信模塊得到執行模塊返回的結果或數據,然后對結果或數據進行包裝,發送到控制節點的管理模塊。工作流程如圖3 所示。

圖3 訪問控制配置模塊工作流程

3.3.2 訪問控制執行模塊

訪問控制執行模塊負責訪問控制機制的具體執行。運行在Hypervisor 層,訪問控制執行模塊可以更好地監控到客戶虛擬機對系統資源的訪問,同時也可以避免遭受破壞,因為Hypervisor 有很高的系統權限。

訪問控制執行模塊的基本工作就是,通過鉤子函數在計算節點上對虛擬機資源的訪問進行強制訪問控制。當計算節點的虛擬機需要對任意系統資源進行訪問時,訪問控制執行模塊會截獲這一訪問請求,之后根據配置模塊加載的安全策略來判斷是否允許該訪問。訪問控制工作流程如圖4 所示。

圖4 訪問控制執行模塊工作流程

3.4 基于云資源控制的隔離機制設計

本文中隔離機制的設計思路是采用對云計算資源進行控制的方式來實現虛擬機的隔離,而這一過程對用戶是完全透明的。隔離機制工作在云控制節點上,依賴于云計算提供的多計算節點架構實現功能。

前文已經介紹過隔離機制基于中國墻策略模型。隔離機制通過對云計算節點進行資源控制,根據用戶提供的可安全要求,將這些利益相關用戶的虛擬機運行在不同計算節點上對它們進行隔離,這樣就可以在很大程度上避免惡意用戶對同一物理平臺上其他利益相關用戶的信息進行竊取。在一臺虛擬機創建或遷移時,隔離機制會根據該虛擬機標簽、沖突集信息以及云平臺虛擬機運行狀態,判斷哪些計算節點正在運行與其有安全利益沖突的虛擬機,使得新虛擬機不會被創建在這些計算節點上,從而避免非法的信息流動。

本文的設計中,隔離控制流程工作在控制節點上,在虛擬機創建或遷移時對其進行調度,以確保其能工作在安全的計算節點上。為了保證這一功能的實現,除了需要安全管理模塊提供的管理、策略部署和數據維護等功能的支持外,還需要對云計算平臺虛擬機的建立流程進行改變,增加一個隔離調度控制流程。圖5 為隔離機制的工作流程。

圖5 隔離控制流程

如圖5 所示,虛線左側中為一般云計算虛擬機創建流程,而右邊則是本文中為了實現隔離機制增加的工作流程。本機制的具體工作流程描述如下：

(1) 通過API 調用發來啟動虛擬機命令及部分虛擬機基本要求,如資源要求等；

(2) 云控制節點收到這些數據后會執行啟動初始化工作,分配其他基本信息,如虛擬機UUID 等；

(3) 云控制節點將根據用戶對資源如內存等的要求開始對計算節點篩選,得到滿足用戶資源要求的計算節點列表；

(4) 完成以上工作后由開始隔離機制控制流程進行處理。通過隔離機制提供的接口將虛擬機信息及(3)所選出的計算節點列表傳遞到該流程中；

(5) 隔離控制流程從本文的安全管理模塊中獲取虛擬機的安全標簽等信息；

(6) 隔離控制流程根據平臺各計算節點虛擬機運行狀態表,對要建立的虛擬機標簽及安全策略進行比對,挑選出符合安全要求的計算節點列表并返回；

(7) 云平臺管理程序從(5)返回的列表中選出一個計算節點為建立虛擬機的目標節點；

(8) 安全管理模塊將目標計算節點及虛擬機標簽信息記錄,以備后續虛擬機創建流程使用；

(9) 云平臺管理程序下發虛擬機創建命令及數據到目標節點,完成虛擬機的創建。

4 系統實現

本文在基于XEN 虛擬化環境的OPENSTACK云平臺上實現了上述安全機制。在管理節點實現了安全管理模塊和基于云計算資源控制的隔離機制,在計算節點實現了訪問控制配置模塊和訪問控制執行模塊。

4.1 安全管理模塊實現

安全管理模塊需要提供接口響應對其的調用請求,應作為一個守護進程存在于控制節點中來監聽來自云平臺其他組件的連接。采用socket 通信作為提供接口的方式。

連接建立后主程序會判斷發送來的操作,主要有用戶注冊生成、虛擬機建立開始和結束操作,然后調用響應的功能函數進行處理來完成操作。實現了manage_core 類來完成安全管理模塊所需要進行的所有管理操作。

最后,安全管理模塊在與計算節點通信功能的設計上不會維護計算節點的IP 地址等信息,而是通過調用OPENSTACK 的RESTFUL[10]接口來獲取信息,將數據及命令下發。

4.2 訪問控制機制的實現

4.2.1 訪問控制配置模塊

訪問控制配置模塊在實現上同樣作為一個守護進程常駐各計算節點的內存中,響應云控制節點發出的命令。本模塊針對云控制節點的要求實現了對虛擬機及資源標簽的添加、安全策略的加載及變更功能。在與云控制節點的通信上通過socket 機制監聽端口,而在對下層訪問控制執行模塊的管理上采用了調用XenAPI[11]的方式。

啟動訪問控制通信模塊程序后會監聽socket 端口并初始化一個mac_conf 類的對象來處理各種云控制節點發來的命令。在mac_conf 對象初始化過程中會與XenAPI 進行連接。

當訪問控制通信模塊主程序接收到來自云控制節點的命令時,會調用mac_conf 類對應的方法進行處理。例如,在需要對虛擬機標簽進行變更時,首先會對屬于該虛擬機的資源標簽進行修改,如VIF 和vDisk 兩類,之后再完成對虛擬機標簽的修改。此外,還實現一些其他的輔助操作,如掛起、恢復虛擬機等對云計算訪問控制機制提供支持。

4.2.2 訪問控制執行模塊

本文的訪問控制執行模塊依托于XEN 提供的XSM 架構以及sHype 機制來實現。sHype 是IBM開發的一種基于XSM 架構實現的安全機制,它已與XEN 代碼高度結合,為XEN 的資源訪問提供強制訪問控制機制,并且不會帶來過高的系統開銷。sHype 架構如圖6 所示。

圖6 sHype 架構

本文中訪問控制執行模塊只需要運行在底層的對鉤子函數的處理等部分,而不需要原來sHype 管理部分的功能。因此,在本文中對sHype 實現的功能進行了簡化,保留對鉤子函數的實現,而將管理部分與訪問控制通信模塊對接,由XenAPI 直接調用,避免了很多配置不當帶來的錯誤。對其進行精簡作為訪問控制執行模塊。

4.3 隔離機制實現

本文隔離控制流程的實現依賴于OPENSTACK提供的Filters 過濾器機制[12]。OPENSTACK 在創建不同虛擬機的過程中會根據虛擬機不同的資源等要求從若干計算節點中篩選出符合要求、可以建立該虛擬機的計算節點。而Filters 機制顧名思義是通過過濾的方式將不符合要求的計算節點從計算節點列表中過濾出去。Filters 機制提供了一種統一的框架,可以編寫自己的Filter 并對虛擬機創建流程進行修改。具體實現流程如下：

需要對OPENSTACK 創建虛擬機的流程進行修改,在創建虛擬機時要能夠調用安全管理模塊,根據要建立的目標虛擬機的用戶信息獲取對應的安全標簽,之后與系統分配的VM UUID 形成一個虛擬機名稱、標簽以及UUID 三元組并記錄。

在完成一系列其他配置和操作后,創建虛擬機的流程會轉到scheduler 進程來對計算節點列表進行篩選,隔離控制流程主要實現也就在這一部分。scheduler 進程的調用配置好的過濾器Filters 對計算節點處理,通過所有Filters 則被認為可以啟動目標虛擬機。因此,實現了一個Filter 進行隔離控制,保證不符合安全要求,即存在于目標虛擬機安全標簽沖突的虛擬機的計算節點無法通過篩選。實現的filter 的主要工作流程如下：

(1) 獲取以參數形式傳入的目標虛擬機uuid 及安全標簽；

(2) 獲取配置好的沖突集信息；

(3) 判斷目標虛擬機標簽是否存在于任意沖突集中,若無返回真,說明目標虛擬機不與任何虛擬機沖突,若否轉到(4)；

(4) 判斷運行在當前節點上的虛擬機的標簽中是否有與目標虛擬機標簽沖突的,若存在,返回假,目標虛擬機無法在本節點啟動；若不存在,返回真,目標虛擬機可以在本節點啟動。

4.4 實驗結果

為了驗證本文中訪問控制機制的有效性和實用性,設計了簡單的實驗來對其主要功能進行測試。首先建立一個包含1 臺控制節點、3 臺計算節點folsom-compute,ubuntu-compute 和openstack-compute的OPENSTACK 云 計 算 環 境。其 中,openstackcompute 計算節點配置為CPU Intel Xeon E7320,內存12 GB,硬盤容量400 GB；folsom-compute 計算節點配置為Intel Core2 6300,內存2 GB,硬盤容量120 GB；ubuntu-compute 計算節點為Core2 6300,內存4 GB,硬盤容量120 GB。

首先,在未應用本文安全機制的情況下,在該云環境中建立4 臺虛擬機。由于openstack-compute 計算節點資源遠多于folsom-compute 及ubuntu-compute節點,控制節點會自動將4 臺虛擬機均下發到openstack-compute 節點。并且由于沒有訪問控制機制,虛擬機間可以相互訪問虛擬磁盤等資源。例如將Test_vm2 的磁盤掛載給Test_vm1,而Test_vm1 可以正常訪問,這可以模擬當計算節點特權被竊取時的攻擊。實驗結果得出：虛擬機Test_vm1,Test_vm2,Test_vm3,Test_vm4,資源要求為512 GB Ram,內存10 GB,所在計算節點為openstack-compute,資源訪問無限制。

之后,在該云環境中啟用了本文實現的安全機制進行對比實驗。通過安全機制提供的接口設定3 個安全標簽corpA.d1,corpA.d2 和corpA.d3 及1 個包含這3 個標簽的沖突集conf1,并將包含這些信息的安全策略文件部署在云環境中。隨后,通過云控制節點建立4 臺資源要求與上一組完全相同的虛擬機,其中虛擬機Test_vm5 標簽為corpA.d1,Test_vm6 標簽為corpA.d2,虛擬機Test_vm7,Test_vm8 標簽為corpA.d3。實驗結果如表1 所示,其中,資源要求為512 GB Ram,內存10 GB。

表1 本文安全機制的應用情況

從實驗結果可以看出,當在openstack-compute計算節點建立安全標簽為corpA.d1 的虛擬機Test_vm5 后,在控制節點實現的隔離控制流程會發揮作用,根據中國墻策略會將下一個建立的虛擬機Test_vm6 發送到無沖突虛擬機且資源更多的ubuntucompute 計算節點。同理,隨后建立的Test_vm7,Test_vm8 也會由于隔離機制的作用,被分配到folsom-compute 節點。

5 結束語

本文針對云計算虛擬化技術存在的安全問題進行研究,結合云計算資源共享及開放性的特點,實現了云計算環境下的強制訪問控制和隔離機制2 種安全機制來保證客戶虛擬機系統的安全。建立了集中管理、分布式實施的云計算訪問控制機制,以及基于云計算資源控制的隔離機制,并編程實現了云計算上述及所依賴的功能。本文實現的安全機制從2 個方面對云計算虛擬機安全進行了加強,實驗結果表明對提升云計算虛擬化安全性、保證客戶虛擬機安全有積極的作用。

然而,本文實現的安全機制只是軟件的安全機制。在當前網絡和云計算安全形勢嚴峻的情況下,軟件安全機制需要與硬件機制相結合,如TPM/TCM 等才能更好地保證自身的安全。這也是本文安全機制有待提高和改進的地方。

[1]馮登國,張 敏,張 妍,等.云計算安全研究[J].軟件學報,2011,22(1)：71-83.

[2]Ristenpart T,Tromer E,Shacham H,et al.Hey,You,Get Off of My Cloud：Exploring Information Leakage in Third-party Compute Clouds[C]//Proceedings of the 16th ACM Conference on Computer and Communications Security.[ S.l.]：ACM Press,2009：199-212.

[3]吳敬征,丁麗萍,王永吉.云計算環境下隱蔽信道關鍵問題研究[J].通信學報,2011,32(9)：184-203.

[4]Jones S T,Arpaci-Dusseau A C,Arpaci-Dusseau R H.Antfarm：Tracking Processes in a Virtual Machine Environment [C]//Proceedings of USENIX Annual Technical Conference.Berkeley,USA：[s.n.],2006：1-14.

[5]Sailer R,Jaeger T,Valdez E,et al.Building a MAC Based Security Architecture for the Xen Opensource Hypervisor [ C]//Proceedings of the 21st Annual Computer Security Applications Conference.[S.l.]：IEEE Press,2005：285-294.

[6]Payne B D,Carbone M,Lee W.Secure and Flexible Monitoring of Virtual Machines[C]//Proceedings of the 23rd Annual Computer Security Applications Conference.Piscataway,USA：IEEE Press,2007：386-397.

[7]Jiang Xuxian,Wang Xinyuan,Xu Dongyan.Stealthy Malware Detection Through VMM-based“out-of-thebox”Semantic View Reconstruction[C]//Proceedings of the 14th ACM Conference on Computer and Communications Security.New York,USA：ACM Press,2007：128-138.

[8]Badger L,Sterne D F,Sherman D L,et al.A Domain and Type Enforcement UNIX Prototype[J].USENIX Computing Systems,1996,9(1)：47-83.

[9]石文昌.操作系統信任基的設計研究[J].武漢大學學報：信息科學版,2010,35(5)：505-508.

[10]Openstack API Complete Reference[EB/OL].(2014-01-30).http：//api.openstack.org/api-ref-guides/bk-apiref.pdf.

[11]Xen Management API v1.0.6 [EB/OL].(2008-12-07).http：//downloads.xen.org/Wiki/XenAPI/xenapi-1.0.6.pdf.

[12]OpenStack Compute Administration Guide[EB/OL].(2013-04-13).http：//docs.openstack.org/grizzly/openstack-compute/admin/content/index.html.