借鑒可信計算思想，從可信增強的角度出發，提出了一個可信增強的訪問控制框架，并給出了該框架的具體實施流程。該框架在普通Flask的基礎上引入了身份認證和可信監控機制，解決了傳統訪問控制中存在的“內部威脅”問題，它是在訪問控制中引入可信計算的一個嘗試，具有一定的指導意義。

目前，大部分終端平臺信息安全系統主要是由防火墻、入侵監測和病毒防范等組成，但僅靠“堵漏洞、作高墻、防外攻”無法從根本上解決終端平臺的安全問題。縱觀安全操作系統近40年的發展歷史可以發現，安全操作系統得到了長足的發展，并在訪問控制框架和安全模型方面均取得了豐碩的成果。但是，傳統的訪問控制并不能解決“內部威脅”問題。造成內部威脅的原因主要是“脆弱性或漏洞攻擊”。“脆弱性或漏洞攻擊”是指內部授權主體可以繞過檢測和訪問控制機制，利用自身的權限和已知的系統脆弱性及漏洞，通過完全合法的操作發動內部攻擊。從技術上講，這種內部威脅的根源在于傳統的訪問控制理論存在的缺陷。傳統的訪問控制理論是基于“關口控制”理論實施的，即它不會讓不符合條件的主體對客體進行請求的操作，但是主體一旦取得相應的操作權限，它在允許操作范圍內的活動行為就可以暢通無阻。究其原因，主體對客體的訪問和行為是根據授權和身份識別來決定的，授權一旦確定，就不會再考慮主體的表現，也不會再考慮主體行為的可信性，直到另外一次授權開始。另外，傳統的訪問控制也不能保證客體內容的真實性和完整性。

因此，尋求一種通用的方法對授權操作的行為進行監管，控制授權后的信息流失，保證合法主體的行為得到應有的控制和監督，才能使這類主體的行為規范可信，預防和控制內部威脅的發生。目前，隨著新的安全技術的興起，可信計算也成為人們關注的熱點。從可信計算的概念及其特征可以發現，通過引入可信計算解決上述安全問題是可行的。

1 可信計算思想

為了提高計算機的安全防護能力，由Intel、惠普、微軟、IBM等業界大公司牽頭，于1999年成立了可信計算平臺聯盟TCPA（后于2003年改組為TCG），并提出了“可信計算”的概念。可信計算旨在從硬件體系結構和系統完整性角度來提高終端計算平臺的安全性，解決終端平臺安全性問題。它認為如果終端計算平臺從一個初始的“可信根”出發，在終端平臺計算環境的每一次轉換時，這種可信狀態都可以通過傳遞的方式保持下去而不被破壞，則該終端平臺就始終是可信的。在可信環境下不存在不被信任的實體，因而可以很好地保證平臺本身及上層應用的安全。

信任鏈的傳遞是體現可信的重要手段，它是可信計算平臺的核心機制。系統加電后，在可信硬件平臺的控制下，BIOS會將信任傳遞給主引導分區，主引導分區將信任傳遞給操作系統裝載器，操作系統裝載器將信任傳遞給操作系統內核模塊，也就是說可信鏈的傳遞是分層進行的。當低級別的節點驗證到高一級的節點是可信時，低級別節點才會把可信計算平臺的運行控制權轉交給高一級節點。可信計算平臺正是基于這種信任鏈傳遞的機制將可信擴展到了應用程序部分。平臺可信的驗證通過哈希運算進行，在驗證過程中，各程序的雜湊值將會被存儲在平臺配置寄存器PCR（Platform. Configuration registers）中，而且在關機之前這部分PCR的值不會被重置，只能被擴展。當遠程或本地程序（請求者）需要驗證當前系統是否處于預定義的可信狀態時，這些PCR的值就會被讀取。請求者對這些可執行體或數據進行雜湊運算，并且與PCR中的預期值進行比較。如果相同，則可以判定該系統運行的程序是預先規定的可信程序或者是可信數據。

2 可信增強的Flask訪問控制框架的設計與分析

2.1 Flask訪問控制框架

Flask是目前業界關注度最高的訪問控制框架之一，它是由美國國家安全局聯合猶他州大學和安全計算公司，以安全策略靈活性為目標設計開發的多訪問控制策略支持框架。Flask嚴格分離了策略實施邏輯和策略決策邏輯。Flask由對象管理器和安全服務器兩部分組成，對象管理器負責策略實施邏輯的執行，安全服務器負責策略決策邏輯的制定。Flask描述了對象管理器和安全服務器的交互，以及對它們內部組成部分的要求。Flask還借助一個訪問向量緩存（AVC）模塊來實現對動態策略和性能要求的支持。

如圖1所示，在Flask訪問控制框架下，主體要對客體進行操作。首先要將訪問請求發送到對象管理器，對象管理器收集主客體的安全標簽，對訪問請求進行判斷;對象管理器首先檢查存放在AVC中的訪問向量，如果存在此訪問向量，則直接返回在AVC中的訪問向量，否則，向安全服務器提出查詢請求。在安全服務器中根據主客體的SID及相應的類，針對相關的安全策略對請求進行計算，然后返回相應的訪問向量決策，同時把此訪問向量存放在AVC中。如果策略允許主體在客體上執行預期的操作，則該請求就會被允許，否則，該請求就會被拒絕。

2.2 可信增強的Flask訪問控制框架設計

盡管Flask安全框架在一定程度上解決了系統的安全問題，但其解決的是不讓非法主體對系統資源進行惡意的訪問控制，而無法解決合法主體的可信性問題，即前言中描述的“內部威脅”問題。另一方面，Flask也無法保證系統中客體內容的完整性和真實性問題。結合可信計算，本文提出了一種可信增強的Flask 訪問控制框架，它在普通Flask框架的基礎上加入了身份認證和可信監控機制，如圖2所示。

訪問控制中，用戶身份認證是非常重要的。在用戶對系統資源進行訪問控制之前，首先要經過身份認證模塊識別用戶的身份，訪問控制模塊才能根據用戶的身份和安全策略庫決定用戶是否能夠訪問某個資源。

可信監控機制用于保障安全策略的正確實施，它在安全服務器內實現。其主要工作有：（1）對主體行為進行監控，即在進行訪問控制之前，確保主體的行為是可信的，不會給系統造成破壞；（2）對客體進行驗證，即根據客體的當前狀態驗證主體的身份和客體自身的完整性，確保客體內容的真實性；（3）監控訪問行為，即監控所有與安全相關的訪問企圖，確保訪問企圖不被篡改，訪問機制不被繞過。圖3是可信監控機制的示意圖。

可信監控機制可分為可信驗證、可信存儲和可信報告三部分，其中可信驗證必須存在，可信存儲和可信報告可選。為了實施可信驗證，首先要對進行可信驗證的實體進行可信度量，可信度量由度量實體（或者是度量事件）啟動，通過對度量實體進行SHA1運算得到一個雜湊值，度量實體會將這個雜湊值存儲在內核里的一個有序度量列表中，同時將可信度量值報告給存儲在可信硬件里的平臺配置寄存器（PCR），以擴展度量列表。可信驗證結合度量列表中存儲的度量值，對主客體進行一致性驗證，檢查其是否被篡改或破壞，以確保主客體的可信性和完整性。驗證過程依賴于度量列表中存儲的基準度量值與當前狀態的可信度量值的比較。若當前狀態的可信度量值符合基準度量值，則認為該實體（或事件）是可信的［4］。

在加入了身份認證和可信監控之后，訪問控制的工作流程如下：

（1） 在身份鑒別的控制下，用戶登錄，啟動訪問控制模塊；

（2） 主體向對象管理器發送訪問請求，要求對相應的客體進行請求操作；

（3） 對象管理器將訪問請求發送給安全服務器。請求包括主客體標識以及請求類型等；

（4） 安全服務器接收到訪問請求之后，啟動可信監控機制；

（5） 可信監控機制根據主體的當前訪問行為，判斷主體的可信性及主體的這次訪問行為是否為不良行為。如果主體可信并且這次訪問行為完全合法，可信監控機制則會轉向對客體的驗證，否則，拒絕這次訪問；

（6） 可信監控機制根據訪問請求，驗證客體的真實性和完整性，如果驗證出客體的真實性和完整性未遭到破壞，可信監控機制則會將訪問控制權轉向安全服務器的安全決策邏輯的制定，否則，拒絕這次訪問；

（7） 安全服務器根據當前的訪問控制策略庫進行訪問決策的判定，如果這次訪問行為滿足訪問控制策略，則允許主體的這次訪問行為，否則，拒絕本次訪問；

（8） 安全服務器將判定結果返回給對象管理器，對象管理器依據決策結果實施主體對客體的訪問控制；

（9） 可信監控機制實施主體對客體操作的監控，如果出現違規行為，則撤銷此次訪問。

2.3可信增強的Flask訪問控制框架分析

本文通過對普通Flask訪問控制框架加入身份認證和可信監控機制，實現了一個可信增強的訪問控制框架，通過實施這個可信增強的訪問控制框架，可以實現對操作系統終端平臺的機密性、一致性保障，并且具有較好的可用性。下面就這幾個方面做簡要說明。

（1） 一致性：通過在框架中實施可信監控機制對相應主體和客體（包括文件、目錄、進程、套接字等）進行一致性驗證。對主、客體的驗證首先要檢查主、客體是否存在預期摘要值，如果不存在，則為其生成預期摘要值（首次執行）；否則計算主、客體的當前摘要值，并且與保存的預期摘要值進行比較；如果不一致，則拒絕本次訪問請求［5］。這樣做可以保證系統資源的一致性，進而保證整個系統的一致性。

（2） 機密性：通過在框架中實施強制訪問控制對登錄用戶、系統主體以及敏感信息進行處理，有權限的合法可信用戶以及合法可信主體才可訪問相應級別的敏感信息，從而解決了前言中闡述的“內部威脅”問題。對于某些由于意外情況而賦予的訪問許可，通過實施強制訪問控制，其實施范圍也會限定在有限的區域，并且當再次執行訪問控制決策時，也會由于一致性驗證不成功而拒絕訪問，從而保證了整個系統的機密性。

（3） 可用性：身份認證是保證用戶身份合法性及唯一性的方法，而訪問控制的有效性也需要建立在合法主體的基礎之上。該框架在普通Flask框架的基礎上增加了身份認證和可信監控，既解決了用戶身份的合法性又解決了訪問控制實施的可信性，它在保證機密性、一致性的基礎上，對用戶透明，不需用戶干預，具有良好的可用性，并且能與操作系統良好兼容。

3 框架實現

本文以通用硬件平臺和Linux-2.6.19內核為基礎實現了此可信增強訪問控制框架。由于所用通用平臺，不具備TCG定義的可信根，因此原型中采用在其他項目中開發的具備密碼功能和存儲機制的可信支撐模塊作為可信根。限于篇幅，本節只重點闡述這個可信增強的訪問控制框架在內核的實施流程。

3.1 內核修改

可信驗證機制是在位于內核空間的安全服務器內實施的，其主要在以下幾方面對內核進行了修改：

（1） 添加了measure系統調用。真實的可信驗證是在內核中執行的，因此在內核中添加了新的系統調用measure，其主要任務是識別系統（用戶或內核級）上的檢測點，即與執行相關的內容載入的地方，并且在這些位置上插入measure系統調用（或在內核里直接調用檢測代碼）。

（2） 添加了一個checkfile文件。checkfile文件用于存放檢測值列表，包括BIOS、操作系統裝載器、內核以及應用程序的檢測基準值。在初始化可信驗證之前，內核首先要載入檢測值列表文件checkfile，若實際的啟動或者運行過程與預期的不同，則checkfile的驗證將會失敗。不允許對 checkfile文件進行修改，否則攻擊者將會隱蔽完整性相關的行為。checkfile文件使用可信硬件保護。

（3） 在內核代碼中實現訪問控制的關鍵點上插入監控函數monitor。monitor函數用于監控某些關鍵的訪問控制實施，對于在訪問控制中出現的某些意外攻擊，monitor函數返回一個錯誤信息，并通知相應主體訪問被篡改，需要撤銷此次訪問操作。

3.2框架實施

框架的實施過程包括框架的初始化和內核實施兩個階段。前一過程是策略實施的基礎，包括用戶身份認證以及可信環境的建立。用戶身份認證通過TCG規范中的雙向認證來實施，克服了傳統認證方式的缺陷，使得操作系統與用戶可以相互認證，從而確保用戶身份信息正確映射到安全策略中；建立可信環境的目的在于將可信鏈傳遞到應用層以確保系統加電直至可信增強內核裝載完畢各個環節的可信。內核實施包括策略初始化、主客體的完整性度量及驗證以及安全策略的驗證實施。策略初始化是將安全策略配置文件解密并導入內核空間；主客體的完整性度量及驗證是對實施訪問控制操作的主客體進行雜湊運算，與主客體的度量基準值進行比較，以確保主體行為的可信性和客體數據的完整性和真實性。其具體過程將在下面具體描述；策略實施是對通過了完整性驗證的訪問控制依據安全策略庫實施安全策略裁決的過程。整個實施過程中前一環節為下一環節服務，逐層建立了系統的可信計算基（TCB），從而保證了框架實施的可信性。主客體的完整性度量是最為關鍵的步驟，下面將重點介紹。

為了實現對訪問操作涉及的主客體的完整性度量及驗證，本文在Linux內核中加入了一個checkfile文件專門存放度量基準值，其格式如下：

……

fedb1cff009e115f7f5f7b4533667a787798832d（hd0，1）/xen3.0.2.gz

0b397acac72a31aedc5f63c5f597c462e0815ed5 ftp

59e6215c821e78ef20d75bd6b63dd5a8b2af00ee/bin/hostname

……

當主體發起對客體的訪問請求時，對象管理器將訪問請求提交給安全服務器。安全服務器首先調用measure對相應的主客體進行可信檢測與驗證，也即啟動框架中的可信驗證機制checkfile_func（）函數來調用calculate_sha1（）函數，以對相應的主客體進行完整性度量，并且檢查相應的主客體是否存在于checkfile中。如果不存在，則將已計算出的雜湊值擴展到checkfile中，以作為下次判斷的依據；如果存在，則調用 strcmp（）函數將所得的雜湊值與基準值進行比較。若不匹配就顯示警告信息，告訴用戶此次訪問操作的主體或客體的完整性已經被破壞，訪問被拒絕；若匹配，則調用update_checkfile（）函數將所計算出的度量值擴展到checkfile文件中，并且在measure系統調用返回前，擴展相應的PCR寄存器，同時將訪問請求移交給安全策略服務器，由策略服務器檢查是否滿足安全策略。若不滿足，則拒絕本次訪問；若滿足則由對象管理器實施訪問決策。在實施訪問控制的過程中調用monitor監控函數對訪問操作進行監控。圖4是上述實施過程的流程圖。

本文借鑒可信計算思想，從可信增強的角度出發，提出了一個可信增強的訪問控制框架，并給出了該框架的具體實施流程。文章重點闡述了框架的總體設計和實施，旨在體現框架的可信增強思想。相比普通的訪問控制，它可以確保主體行為的可信性、客體內容的完整性和真實性，以及訪問控制行為的正確性。本文提出的這個可信增強的框架是對可信計算在訪問控制中應用的一個嘗試，在下一步工作中，將主要針對框架中存在的一些安全隱患和具體實施細節加以改進。

責任編輯：gt