基于環境屬性的訪問控制系統設計與實現

劉曉威,周 雷,王國軍

(中南大學 信息科學與工程學院,長沙 410083)

0 概述

在信息安全領域的研究中,訪問控制(Access Control,AC)技術作為關鍵技術一直備受關注[1]。在該技術方向上先后提出了自主訪問控制、強制訪問控制、基于角色的訪問控制以及基于屬性的訪問控制等模型[2]。基于屬性的訪問控制模型(Attribute-based Access Control,ABAC)是近些年提出的一種較新的訪問控制模型,其在管理訪問時,按照主體、客體、操作等的屬性是否匹配,來確定訪問是否合法,因此,具有很強的靈活性和擴展性[3]。Linux操作系統是當下科研和商業領域里主流的操作系統,然而其上還沒有建立起成熟的基于屬性的訪問控制機制。當前Linux系統采用基于權限位的自主訪問控制(UGO權限模型)來進行基本的訪問控制,此外Linux逐步增加了ACL機制、Capabilities機制、LSM機制等,同時也增加了SELinux、Smack等安全子系統[4]。然而Linux中這些傳統的訪問控制機制,基本上都指明了主體和客體,權限設置都與主客體相關聯,且在訪問控制過程中固定不變。但在實際情況中,系統的環境屬性對訪問權限也存在很大的影響,若將環境屬性加入到對訪問權限的判斷中將能夠滿足更多的安全需求[5]。

本文構建一種基于環境屬性的訪問控制模型(Environmental Attribute Based Access Control Model,EABAC),該模型將環境屬性加入到訪問控制判定范圍中,動態監測環境屬性的變化,以此來調整訪問控制權限。

1 相關技術原理

1.1 Linux現有的訪問控制機制

Linux屬于多用戶的操作系統,其基本的訪問控制策略是基于權限位的自主訪問控制。系統對用戶采用分組的方式進行管理,用戶組和用戶都有獨立的標識,分別為GID和UID[6]。Linux系統內的用戶被劃分成root、user、group和other 4類,分別指代的是根用戶、文件所屬用戶、文件同組用戶和其他用戶。系統中軟、硬件資源都被當作文件處理,每種文件都分別被定義了讀、寫和執行的權限。文件還有控制權限,默認情況下,文件的創建者是文件的所有者,可自主地控制文件的讀、寫、執行的權限[7]。root用戶在系統中擁有最高權限,不會受到訪問控制的限制。

Linux系統中的權限控制列表(Access Control List,ACL)機制給每個文件都分配一列ACL條目,所有用戶和用戶組的權限都采用ACL條目表示,通過此方式可以為特定的用戶和用戶組設置對文件的訪問權限,其擴大了權限約束的范圍[8]。

Linux系統中的Capabilities機制實現了更加細粒度的權限控制[9]。Capabilities機制將root用戶的權限劃分成更加細粒度的能力,如Linux內核3.13中包含了37種不同的能力,此外與ACL機制將權限策略設置給文件不同,Capabilities機制將權限策略設置給進程。其通過給每個進程設置能力集實現讓一般用戶擁有root用戶的權限,且能實現對root用戶的訪問限制[10]。

1.2 LSM安全框架

Linux安全框架(Linux Security Module,LSM)是從內核2.6版本增加到Linux系統中的一個輕量級通用訪問控制框架,其提供了一個能夠成功實現訪問控制模塊的接口[11],其體系結構如圖1所示。

圖1 LSM體系結構

LSM主要的工作方式,是在內核資源訪問的源碼中,放置了鉤子函數,鉤子函數會在相應的內核資源被訪問時被調用,用戶可以自行在鉤子函數中自定義判定過程,用于對訪問請求進行判斷。鉤子函數位于內核自主訪問控制之后,用戶的訪問請求先需經歷自主訪問控制的過濾,再發送到鉤子函數中進行判定,所以,LSM不會影響Linux系統中原有的訪問控制機制[12]。利用LSM可以完成各種細粒度和復雜的訪問控制,且有著較高的靈活性和安全性。

2 基于環境屬性的訪問控制模型EABAC

2.1 環境屬性的含義

本文所描述的環境屬性定義:與系統安全相關的,表示用戶在訪問系統資源時的系統環境信息以及相關的上下文信息,例如系統的CPU負載、進程數、內存負載、磁盤吞吐量、系統時間等。不同的系統在不同的應用場景下被關注的環境屬性都有所不同,具體在應用時可根據不同的系統特征和應用需求來進行調整。

在實際的應用場景中,若能將當前環境屬性加入到訪問控制權限的判定中,將會使系統的安全性、可用性及用戶體驗得到提高[13]。例如一個提供計算服務的服務器,如果服務器CPU和內存負載不高,每個用戶都能快速地獲取到正常的計算服務。伴隨著訪問量的增加或服務器上運行進程的增加,導致服務器CPU和內存負載過高,若用戶繼續嘗試獲取該服務,服務器的服務進程容易阻塞,并陷入長時間的等待,無法保障用戶及時的獲取服務。更加高效的訪問控制策略是,實時監測服務器的用戶訪問量和CPU、內存負載等信息的變化,當服務器負載過高時,提示用戶暫時無法訪問該服務,或者只允許訪問資源消耗更小的低一級計算服務,而無法訪問之前可訪問的正常計算服務。此場景說明了在客體都未變化的情況下,系統環境屬性對用戶獲取資源也存在很大的影響。傳統的訪問控制策略基本上依據的是主客體的靜態安全信息,在訪問開始前權限即固定,無法動態調整權限。若是能通過環境屬性的變化來調整訪問控制的權限,則能進一步提高系統的安全性和可用性,同時改善用戶體驗。

2.2 EABAC的模型結構

基于訪問控制權限根據動態的環境屬性變化而調整的需求,本文提出基于環境屬性的訪問控制模型EABAC,模型架構如圖2所示。策略分配點(Policy Administration Point,PAP):PAP負責對主體和客體的限制條件進行設置。有2個時間點可以進行設置,一是在訪問開始之前,管理員根據系統狀態、應用要求和安全等級,通過PAP為主體和客體設置限制條件。此外在系統運行過程中,管理員也可以通過PAP修改主體和客體的限制條件。

圖2 EABAC模型結構

環境屬性收集點(Environmental Attribute Collection Point,EACP):EACP負責監控系統的運行狀態,并周期性地收集各項環境屬性值并傳遞給PDP。

策略執行點(Policy Execution Point,PEP):PEP負責接受主體的原始訪問請求,并將訪問請求傳遞給PDP,最后通過接受到的返回結果,決定是否放行該訪問。

策略判定點(Policy Decision Point,PDP):PDP負責接收PEP傳遞的判定請求,并根據從主客體處獲取的限制條件信息,以及EACP傳遞的環境屬性值來對判定請求進行判斷,并將判斷結果返回給策略執行點PEP。

在主體開始訪問客體前,系統管理員通過策略分配點PAP對主體和客體訪問控制的限制條件進行設置,限制條件作為主體和客體的一種標識屬性,其標識了主體對客體的訪問范圍。

主體在訪問客體時,會將原始訪問請求傳遞給策略執行點PEP,策略執行點PEP在接收到主體原始的訪問請求后,將會向策略判定點PDP發送判定請求。策略判定點PDP根據從主體Subject和客體Object中獲取的限制條件以及環境屬性收集點EACP收集到的環境屬性值對判定請求作出判斷,并將響應結果返回給策略執行點PEP,決定是否訪問客體。

環境屬性收集點EACP負責實時收集系統環境屬性,并將收集到的數據傳遞給策略判定點PDP。策略判定點PDP負責對EACP收集到的系統環境屬性進行管理,同時從主體Subject和客體Object中獲取訪問控制的限制條件,并根據系統環境屬性及主客體的限制條件,對訪問請求進行判定。

3 原型系統的設計與實現

3.1 系統總體結構

本文所實現的原型系統包含3個功能模塊,分別是內核判定模塊、用戶控制模塊和通信模塊。內核判定模塊運行于Linux內核空間,負責在內核資源被訪問前,根據當前系統環境的屬性值,對訪問行為進行判定。用戶控制模塊運行于Linux用戶空間,負責實時收集系統的環境屬性值并將其傳遞給內核判定模塊,此外用戶控制模塊還可用來對訪問控制策略進行查看和修改。通信模塊主要用于內核判定模塊和用戶控制模塊之間的數據傳遞。原型系統的系統結構如圖3所示。

圖3 系統架構

系統運行過程中,基于LSM的消息截獲函數將同步執行,用于攔截Linux內核中資源訪問的進程。同時,環境屬性采集程序異步搜集并處理各項系統環境屬性。訪問程序被截獲后,當前系統環境屬性被輸入到預先定義的訪問控制策略中進行決策分析。訪問判定程序將判定當前訪問操作的合法性,合法則繼續執行訪問操作。策略配置模塊用于對文件或目錄的限制條件進行設置,該操作可由系統管理員來完成。

3.2 內核安全模塊

系統中的內核判定模塊采用LSM框架作為基礎平臺實現。LSM目前作為Linux內核補丁的形式實現,其提供了一個通用的基礎體系給安全模塊,允許安全策略以驅動模塊的形式動態加載到Linux內核中。

LSM鉤子函數分布在Linux內核中各個涉及安全操作的函數中,在相關安全操作被執行的時候自動被調用。在本文系統中主要用到和文件操作相關的鉤子函數,如重寫了file_permission和file_alloc_security等鉤子函數。

鉤子函數是定義在全局表security_ops中的函數指針所指向的函數[14]。本文系統定義了自己的全局表eabac_security_ops和自己的鉤子函數,用于監控系統所要監控的訪問操作。安全模塊可通過register_security函數注冊到LSM框架中。

3.3 用戶控制模塊

3.3.1 環境屬性的收集

本文原型系統中涉及到的環境屬性包括CPU負載、內存負載和訪問時間。屬性具體介紹見表1。

表1 環境屬性

環境屬性收集程序是一個守護進程,周期性地收集環境屬性值,并傳遞給內核判定模塊。

1)CPU負載的獲取

CPU負載可以通過proc文件系統獲取。/proc/stat文件中記錄著實時的CPU狀態信息,根據機器的不同,可能存在多核的情況:

cpu 4447387 5090 587215 1520173257 886030 50 6610 0

cpu0 1967877 2115 202061 378871062 395505 46 3575 0

cpu1 1826065 424 228438 379268369 228746 0 970 0

……

這些數據表示從系統啟動到當前時刻不同任務執行累積的時間片,其中,第一行是總的CPU運行時間,下面是單個CPU的運行時間。總的CPU運行時間記為ttotal,可以通過將/proc/stat文件中第1行各參數所表示的運行時間累加得到,總的CPU空閑時間記為tidle,第1行中的第4個值即表示該時間。CPU的使用率是一個瞬時值,可通過式(1)計算單位時間內的平均值來表示:

Rcpu_usage= ((100-(tidle2-tidle1))×100/

(ttotal2-ttotal1))%

(1)

其中,Rcpu_usage表示CPU利用率,tidle1和tidle2分別表示時間段首末時間點CPU空閑時間,ttotal1和ttotal2分別表示時間段首末時間點CPU總的運行時間。

2)內存負載的獲取

內存負載的獲取與CPU負載的獲取類似。/proc/meminfo文件中記錄著系統實時的內存狀態信息,相比于CPU信息,其不存在多核的情況:

memtotal:32865856 kB

memtree:20881780 kB

……

內存利用率通過式(2)計算:

Rmem_usage=((mtotal-mfree)×100/mtotal)%

(2)

其中,Rmem_usage表示內存的使用率,mtotal表示內存總的大小,mfree表示空閑內存的大小。

3)系統時間的獲取

在Linux系統中,通過time函數可以得到自1970年1月1日00∶00∶00(格林威治時間)以來的秒數。對于得到的時間信息,可以再通過ctime函數換算成日常所使用的日期時間表示格式,其返回的字符串格式形如“Wed Jun 28 21∶34∶08 2015”,從該字符串中提取出系統當前時間“21∶34∶08”即可。

3.3.2 文件限制條件的配置

策略配置程序是一個用戶層的控制程序,負責對文件的限制條件進行查看和設置。該用戶層控制程序通過調用inode_setxattr鉤子函數來設置文件限制條件,通過該鉤子函數把環境屬性值寫到文件inode結構的i_security安全域中。此外,open/close系統調用函數執行時,控制程序調用重寫后的file_alloc_security函數,修改或銷毀安全域文件信息。

3.4 系統內模塊間通信

在Linux系統中,由于地址空間的限制,內核代碼和用戶代碼間不能直接調用和訪問[15],需要額外的方式實現它們之間的通信。本文原型系統實現基于proc文件系統和虛擬字符設備2種方式的系統間模塊的通信方式。

定義一個虛擬字符設備作為環境屬性值的傳遞模塊,用戶控制模塊中的環境屬性收集程序,每2 s獲取一次環境屬性值,并以結構體數據格式寫入虛擬字符設備中。內核安全模塊則實時地從虛擬字符設備中讀出環境屬性值。

內核判定模塊中的全局變量,例如內核判定模塊是否啟用、主客體的限制條件環境屬性值等需要提供查詢和修改的接口。本文系統通過在/proc/sys目錄下建立目錄樹以顯示內核中保存的全局變量,通過register_sysctl_table函數實現。

4 實驗結果與分析

4.1 實現平臺

基于環境屬性的訪問控制原型系統采用的實驗平臺參數如表2所示。基于普通的硬件平臺,增加修改模塊后的操作系統,測試訪問控制權限的動態性變化情形。

表2 實驗平臺參數

4.2 測試

4.2.1 功能測試

功能測試的目的是驗證是否成功將CPU負載、內存負載以及訪問時間等環境屬性值添加到了訪問控制的判定過程中。通過預先設置測試文件相關環境屬性的限制條件,然后訪問文件,分析對應環境屬性值,判斷文件是否被訪問。

圖4所示為CPU負載的測試過程,首先,在初始狀態下被測文件hello設置為可訪問,經測試操作,文件可以進行相關訪問操作。其次,執行大數據處理的計算程序,提高當前CPU計算負載,再次訪問hello文件,訪問被拒絕。最后,當結束高負載使用CPU的進程后,測試文件重新被允許訪問。

圖4 CPU負載測試

圖5所示為內存負載的測試過程,首先,在初始狀態下被測文件hello設置為可訪問,經測試操作,文件可以進行相關訪問操作。其次,并行執行高內存負載的程序upmem,該程序分配1 GB的內存,在休眠5 min(模擬upmem執行時間)后訪問hello文件,訪問被拒絕。最后,結束upmem程序運行,測試文件hello重新被允許訪問。

圖5 內存負載測試

實驗結果表明,當CPU、內存等環境屬性的變化導致系統運行存在擁塞等情形中,自適應地調整文件的訪問權限,能有效優化系統服務。

4.2.2 性能測試

性能測試的目的是為了驗證內核判定模塊的添加對文件訪問效率的影響程度。采用的測試方法是通過運行百萬級的文件訪問,記錄對比在不同測試條件下訪問文件的時間。測試中選取3種不同的運行環境以及3種不同的測試文件作為前提,分別如表3和表4所示。

表3 模塊測試條件

表4 文件測試條件

如表3和表4所示,本文實驗設置了3種模塊測試條件,并將對小文件和大文件的文件限制也分成了不同的3種限制條件,目的是為了通過多種測試條件的組合,充分反映內核判定模塊的添加對文件訪問效率的影響。每一種測試條件下的文件操作都執行了二百萬次,且在每種測試條件都執行了3次,最終的測試結果為3次的平均值。

表5～表7中的測試數據記錄是訪問文件三百萬次的時間,分別統計了在未對測試文件設置限制條件、設置了限制條件但未開啟以及設置了限制條件且開啟3種情況下,對小、大文件進行打開、讀和寫操作的時間。從實驗數據可以看出,在添加和未添加內核判定模塊的不同情況下,對文件訪問操作的耗時并沒有出現大的起伏,同時考慮到系統實時運行環境因素對測試的影響以及誤差的存在,可以說明內核判定模塊對文件訪問效率影響很小。通過實驗數據可以得出結論,該訪問控制原型系統所執行的訪問控制效率較高,不會影響到系統的正常運行,同時具備了較高的安全性和可用性。

表5 打開操作的訪問時間 s

表6 讀操作的訪問時間 s

表7 寫操作的訪問時間 s

5 結束語

本文構建一種基于環境屬性的訪問控制模型EABAC,以豐富Linux平臺中的訪問控制機制。該模型將系統的環境屬性加入到訪問判定的過程中,擴展了Linux訪問控制策略的范圍。同時基于EABAC模型開發Linux平臺下的訪問控制原型系統。實驗結果表明,該系統考慮內核空間和用戶空間程序的運行效率,基于LSM框架實現內核判定模塊,具有良好的通用性和可擴展性;在用戶空間為用戶提供友好的控制接口,實現策略的自定義配置。下一步將把更多的環境屬性加入到安全模塊中,添加系統日志等功能,方便系統管理員的審計工作。

[1] 李鳳華,蘇 芒,史國振,等.訪問控制模型研究進展及發展趨勢[J].電子學報,2012,40(4):805-813.

[2] 王小明,付 紅,張立臣.基于屬性的訪問控制研究進展[J].電子學報,2010,38(7):1660-1667.

[3] XU Zhongyuan,STOLLER S.Mini Attribute-based Access Control Policies[J].IEEE Transactions on Dependable on Secure Computing,2014,12(5):533-545.

[4] WANG Zhijie,HUANG Dijiang,ZHU Yan.Efficient Attribute-based Comparable Data Access Control[J].IEEE Transactions on Computer,2015,64(12):3430-3443.

[5] GUPTA P,STOLLER S,XU Zhongyuan.Abductive Analysis of Administrative Policies in Rule-based Access Control[J].IEEE Transactions on Dependable and Secure Computing,2014,11(5):412-424.

[6] 李曉峰,馮登國,陳朝武,等.基于屬性的訪問控制模型[J].通信學報,2008,29(4):90-98.

[7] RICHARD K,EDWARD J,TIMOTHY R.Adding Attributes to Role-based Access Control[J].Computer,2010,43(6):79-81.

[8] 韓道軍,高 潔,翟浩良,等.訪問控制模型研究進展[J].計算機科學,2010,11(7):84-87.

[9] 吳新松,賀也平,周洲儀.一個環境適應的基于角色的訪問控制模型[J].計算機研究與發展,2011,48(6):112-123.

[10] ZHU Yan,HUANG Dijiang,HU Changyun,et al.From RBAC to ABAC:Construction Flexible Data Access Control for Cloud Strorage Services[J].IEEE Tran-sactions on Services Computing,2015,8(4):601-616.

[11] JAEGER T.Operating System Security[J].Systhesis Lectures on Information Security,Privacy and Trust,2008,1(1):1-218.

[12] FERRAIOLO D,SANDHU R,GAVRILA S.Proposed NIST Standard for Role-based Access Control[J].ACM Transactions on Information and System Security,2001,4(3):224-274.

[13] 李唯冠,趙逢禹.帶屬性策略的RBAC權限訪問控制模型[J].小型微型計算機系統,2013,5(9):103-107.

[14] LI Feng,SU Mei,SHI Guzhe.Research Status and Development Trends of Access Control Model[J].Chinese Journal of Electronics,2012,40(4):805-813.

[15] NIU Shaozhang,TU Shanshan,HUANG Yongfeng.An Effective and Secure Access Control System Scheme in Cloud[J].Chinese Journal of Electronics,2015,24(3):524-528.