劉曉威,周 雷,王國軍
(中南大學(xué) 信息科學(xué)與工程學(xué)院,長沙 410083)
在信息安全領(lǐng)域的研究中,訪問控制(Access Control,AC)技術(shù)作為關(guān)鍵技術(shù)一直備受關(guān)注[1]。在該技術(shù)方向上先后提出了自主訪問控制、強(qiáng)制訪問控制、基于角色的訪問控制以及基于屬性的訪問控制等模型[2]?;趯傩缘脑L問控制模型(Attribute-based Access Control,ABAC)是近些年提出的一種較新的訪問控制模型,其在管理訪問時(shí),按照主體、客體、操作等的屬性是否匹配,來確定訪問是否合法,因此,具有很強(qiáng)的靈活性和擴(kuò)展性[3]。Linux操作系統(tǒng)是當(dāng)下科研和商業(yè)領(lǐng)域里主流的操作系統(tǒng),然而其上還沒有建立起成熟的基于屬性的訪問控制機(jī)制。當(dāng)前Linux系統(tǒng)采用基于權(quán)限位的自主訪問控制(UGO權(quán)限模型)來進(jìn)行基本的訪問控制,此外Linux逐步增加了ACL機(jī)制、Capabilities機(jī)制、LSM機(jī)制等,同時(shí)也增加了SELinux、Smack等安全子系統(tǒng)[4]。然而Linux中這些傳統(tǒng)的訪問控制機(jī)制,基本上都指明了主體和客體,權(quán)限設(shè)置都與主客體相關(guān)聯(lián),且在訪問控制過程中固定不變。但在實(shí)際情況中,系統(tǒng)的環(huán)境屬性對訪問權(quán)限也存在很大的影響,若將環(huán)境屬性加入到對訪問權(quán)限的判斷中將能夠滿足更多的安全需求[5]。
本文構(gòu)建一種基于環(huán)境屬性的訪問控制模型(Environmental Attribute Based Access Control Model,EABAC),該模型將環(huán)境屬性加入到訪問控制判定范圍中,動態(tài)監(jiān)測環(huán)境屬性的變化,以此來調(diào)整訪問控制權(quán)限。
Linux屬于多用戶的操作系統(tǒng),其基本的訪問控制策略是基于權(quán)限位的自主訪問控制。系統(tǒng)對用戶采用分組的方式進(jìn)行管理,用戶組和用戶都有獨(dú)立的標(biāo)識,分別為GID和UID[6]。Linux系統(tǒng)內(nèi)的用戶被劃分成root、user、group和other 4類,分別指代的是根用戶、文件所屬用戶、文件同組用戶和其他用戶。系統(tǒng)中軟、硬件資源都被當(dāng)作文件處理,每種文件都分別被定義了讀、寫和執(zhí)行的權(quán)限。文件還有控制權(quán)限,默認(rèn)情況下,文件的創(chuàng)建者是文件的所有者,可自主地控制文件的讀、寫、執(zhí)行的權(quán)限[7]。root用戶在系統(tǒng)中擁有最高權(quán)限,不會受到訪問控制的限制。
Linux系統(tǒng)中的權(quán)限控制列表(Access Control List,ACL)機(jī)制給每個(gè)文件都分配一列ACL條目,所有用戶和用戶組的權(quán)限都采用ACL條目表示,通過此方式可以為特定的用戶和用戶組設(shè)置對文件的訪問權(quán)限,其擴(kuò)大了權(quán)限約束的范圍[8]。
Linux系統(tǒng)中的Capabilities機(jī)制實(shí)現(xiàn)了更加細(xì)粒度的權(quán)限控制[9]。Capabilities機(jī)制將root用戶的權(quán)限劃分成更加細(xì)粒度的能力,如Linux內(nèi)核3.13中包含了37種不同的能力,此外與ACL機(jī)制將權(quán)限策略設(shè)置給文件不同,Capabilities機(jī)制將權(quán)限策略設(shè)置給進(jìn)程。其通過給每個(gè)進(jìn)程設(shè)置能力集實(shí)現(xiàn)讓一般用戶擁有root用戶的權(quán)限,且能實(shí)現(xiàn)對root用戶的訪問限制[10]。
Linux安全框架(Linux Security Module,LSM)是從內(nèi)核2.6版本增加到Linux系統(tǒng)中的一個(gè)輕量級通用訪問控制框架,其提供了一個(gè)能夠成功實(shí)現(xiàn)訪問控制模塊的接口[11],其體系結(jié)構(gòu)如圖1所示。
圖1 LSM體系結(jié)構(gòu)
LSM主要的工作方式,是在內(nèi)核資源訪問的源碼中,放置了鉤子函數(shù),鉤子函數(shù)會在相應(yīng)的內(nèi)核資源被訪問時(shí)被調(diào)用,用戶可以自行在鉤子函數(shù)中自定義判定過程,用于對訪問請求進(jìn)行判斷。鉤子函數(shù)位于內(nèi)核自主訪問控制之后,用戶的訪問請求先需經(jīng)歷自主訪問控制的過濾,再發(fā)送到鉤子函數(shù)中進(jìn)行判定,所以,LSM不會影響Linux系統(tǒng)中原有的訪問控制機(jī)制[12]。利用LSM可以完成各種細(xì)粒度和復(fù)雜的訪問控制,且有著較高的靈活性和安全性。
本文所描述的環(huán)境屬性定義:與系統(tǒng)安全相關(guān)的,表示用戶在訪問系統(tǒng)資源時(shí)的系統(tǒng)環(huán)境信息以及相關(guān)的上下文信息,例如系統(tǒng)的CPU負(fù)載、進(jìn)程數(shù)、內(nèi)存負(fù)載、磁盤吞吐量、系統(tǒng)時(shí)間等。不同的系統(tǒng)在不同的應(yīng)用場景下被關(guān)注的環(huán)境屬性都有所不同,具體在應(yīng)用時(shí)可根據(jù)不同的系統(tǒng)特征和應(yīng)用需求來進(jìn)行調(diào)整。
在實(shí)際的應(yīng)用場景中,若能將當(dāng)前環(huán)境屬性加入到訪問控制權(quán)限的判定中,將會使系統(tǒng)的安全性、可用性及用戶體驗(yàn)得到提高[13]。例如一個(gè)提供計(jì)算服務(wù)的服務(wù)器,如果服務(wù)器CPU和內(nèi)存負(fù)載不高,每個(gè)用戶都能快速地獲取到正常的計(jì)算服務(wù)。伴隨著訪問量的增加或服務(wù)器上運(yùn)行進(jìn)程的增加,導(dǎo)致服務(wù)器CPU和內(nèi)存負(fù)載過高,若用戶繼續(xù)嘗試獲取該服務(wù),服務(wù)器的服務(wù)進(jìn)程容易阻塞,并陷入長時(shí)間的等待,無法保障用戶及時(shí)的獲取服務(wù)。更加高效的訪問控制策略是,實(shí)時(shí)監(jiān)測服務(wù)器的用戶訪問量和CPU、內(nèi)存負(fù)載等信息的變化,當(dāng)服務(wù)器負(fù)載過高時(shí),提示用戶暫時(shí)無法訪問該服務(wù),或者只允許訪問資源消耗更小的低一級計(jì)算服務(wù),而無法訪問之前可訪問的正常計(jì)算服務(wù)。此場景說明了在客體都未變化的情況下,系統(tǒng)環(huán)境屬性對用戶獲取資源也存在很大的影響。傳統(tǒng)的訪問控制策略基本上依據(jù)的是主客體的靜態(tài)安全信息,在訪問開始前權(quán)限即固定,無法動態(tài)調(diào)整權(quán)限。若是能通過環(huán)境屬性的變化來調(diào)整訪問控制的權(quán)限,則能進(jìn)一步提高系統(tǒng)的安全性和可用性,同時(shí)改善用戶體驗(yàn)。
基于訪問控制權(quán)限根據(jù)動態(tài)的環(huán)境屬性變化而調(diào)整的需求,本文提出基于環(huán)境屬性的訪問控制模型EABAC,模型架構(gòu)如圖2所示。策略分配點(diǎn)(Policy Administration Point,PAP):PAP負(fù)責(zé)對主體和客體的限制條件進(jìn)行設(shè)置。有2個(gè)時(shí)間點(diǎn)可以進(jìn)行設(shè)置,一是在訪問開始之前,管理員根據(jù)系統(tǒng)狀態(tài)、應(yīng)用要求和安全等級,通過PAP為主體和客體設(shè)置限制條件。此外在系統(tǒng)運(yùn)行過程中,管理員也可以通過PAP修改主體和客體的限制條件。
圖2 EABAC模型結(jié)構(gòu)
環(huán)境屬性收集點(diǎn)(Environmental Attribute Collection Point,EACP):EACP負(fù)責(zé)監(jiān)控系統(tǒng)的運(yùn)行狀態(tài),并周期性地收集各項(xiàng)環(huán)境屬性值并傳遞給PDP。
策略執(zhí)行點(diǎn)(Policy Execution Point,PEP):PEP負(fù)責(zé)接受主體的原始訪問請求,并將訪問請求傳遞給PDP,最后通過接受到的返回結(jié)果,決定是否放行該訪問。
策略判定點(diǎn)(Policy Decision Point,PDP):PDP負(fù)責(zé)接收PEP傳遞的判定請求,并根據(jù)從主客體處獲取的限制條件信息,以及EACP傳遞的環(huán)境屬性值來對判定請求進(jìn)行判斷,并將判斷結(jié)果返回給策略執(zhí)行點(diǎn)PEP。
在主體開始訪問客體前,系統(tǒng)管理員通過策略分配點(diǎn)PAP對主體和客體訪問控制的限制條件進(jìn)行設(shè)置,限制條件作為主體和客體的一種標(biāo)識屬性,其標(biāo)識了主體對客體的訪問范圍。
主體在訪問客體時(shí),會將原始訪問請求傳遞給策略執(zhí)行點(diǎn)PEP,策略執(zhí)行點(diǎn)PEP在接收到主體原始的訪問請求后,將會向策略判定點(diǎn)PDP發(fā)送判定請求。策略判定點(diǎn)PDP根據(jù)從主體Subject和客體Object中獲取的限制條件以及環(huán)境屬性收集點(diǎn)EACP收集到的環(huán)境屬性值對判定請求作出判斷,并將響應(yīng)結(jié)果返回給策略執(zhí)行點(diǎn)PEP,決定是否訪問客體。
環(huán)境屬性收集點(diǎn)EACP負(fù)責(zé)實(shí)時(shí)收集系統(tǒng)環(huán)境屬性,并將收集到的數(shù)據(jù)傳遞給策略判定點(diǎn)PDP。策略判定點(diǎn)PDP負(fù)責(zé)對EACP收集到的系統(tǒng)環(huán)境屬性進(jìn)行管理,同時(shí)從主體Subject和客體Object中獲取訪問控制的限制條件,并根據(jù)系統(tǒng)環(huán)境屬性及主客體的限制條件,對訪問請求進(jìn)行判定。
本文所實(shí)現(xiàn)的原型系統(tǒng)包含3個(gè)功能模塊,分別是內(nèi)核判定模塊、用戶控制模塊和通信模塊。內(nèi)核判定模塊運(yùn)行于Linux內(nèi)核空間,負(fù)責(zé)在內(nèi)核資源被訪問前,根據(jù)當(dāng)前系統(tǒng)環(huán)境的屬性值,對訪問行為進(jìn)行判定。用戶控制模塊運(yùn)行于Linux用戶空間,負(fù)責(zé)實(shí)時(shí)收集系統(tǒng)的環(huán)境屬性值并將其傳遞給內(nèi)核判定模塊,此外用戶控制模塊還可用來對訪問控制策略進(jìn)行查看和修改。通信模塊主要用于內(nèi)核判定模塊和用戶控制模塊之間的數(shù)據(jù)傳遞。原型系統(tǒng)的系統(tǒng)結(jié)構(gòu)如圖3所示。
圖3 系統(tǒng)架構(gòu)
系統(tǒng)運(yùn)行過程中,基于LSM的消息截獲函數(shù)將同步執(zhí)行,用于攔截Linux內(nèi)核中資源訪問的進(jìn)程。同時(shí),環(huán)境屬性采集程序異步搜集并處理各項(xiàng)系統(tǒng)環(huán)境屬性。訪問程序被截獲后,當(dāng)前系統(tǒng)環(huán)境屬性被輸入到預(yù)先定義的訪問控制策略中進(jìn)行決策分析。訪問判定程序?qū)⑴卸ó?dāng)前訪問操作的合法性,合法則繼續(xù)執(zhí)行訪問操作。策略配置模塊用于對文件或目錄的限制條件進(jìn)行設(shè)置,該操作可由系統(tǒng)管理員來完成。
系統(tǒng)中的內(nèi)核判定模塊采用LSM框架作為基礎(chǔ)平臺實(shí)現(xiàn)。LSM目前作為Linux內(nèi)核補(bǔ)丁的形式實(shí)現(xiàn),其提供了一個(gè)通用的基礎(chǔ)體系給安全模塊,允許安全策略以驅(qū)動模塊的形式動態(tài)加載到Linux內(nèi)核中。
LSM鉤子函數(shù)分布在Linux內(nèi)核中各個(gè)涉及安全操作的函數(shù)中,在相關(guān)安全操作被執(zhí)行的時(shí)候自動被調(diào)用。在本文系統(tǒng)中主要用到和文件操作相關(guān)的鉤子函數(shù),如重寫了file_permission和file_alloc_security等鉤子函數(shù)。
鉤子函數(shù)是定義在全局表security_ops中的函數(shù)指針?biāo)赶虻暮瘮?shù)[14]。本文系統(tǒng)定義了自己的全局表eabac_security_ops和自己的鉤子函數(shù),用于監(jiān)控系統(tǒng)所要監(jiān)控的訪問操作。安全模塊可通過register_security函數(shù)注冊到LSM框架中。
3.3.1 環(huán)境屬性的收集
本文原型系統(tǒng)中涉及到的環(huán)境屬性包括CPU負(fù)載、內(nèi)存負(fù)載和訪問時(shí)間。屬性具體介紹見表1。
表1 環(huán)境屬性
環(huán)境屬性收集程序是一個(gè)守護(hù)進(jìn)程,周期性地收集環(huán)境屬性值,并傳遞給內(nèi)核判定模塊。
1)CPU負(fù)載的獲取
CPU負(fù)載可以通過proc文件系統(tǒng)獲取。/proc/stat文件中記錄著實(shí)時(shí)的CPU狀態(tài)信息,根據(jù)機(jī)器的不同,可能存在多核的情況:
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
……
這些數(shù)據(jù)表示從系統(tǒng)啟動到當(dāng)前時(shí)刻不同任務(wù)執(zhí)行累積的時(shí)間片,其中,第一行是總的CPU運(yùn)行時(shí)間,下面是單個(gè)CPU的運(yùn)行時(shí)間??偟腃PU運(yùn)行時(shí)間記為ttotal,可以通過將/proc/stat文件中第1行各參數(shù)所表示的運(yùn)行時(shí)間累加得到,總的CPU空閑時(shí)間記為tidle,第1行中的第4個(gè)值即表示該時(shí)間。CPU的使用率是一個(gè)瞬時(shí)值,可通過式(1)計(jì)算單位時(shí)間內(nèi)的平均值來表示:
Rcpu_usage= ((100-(tidle2-tidle1))×100/
(ttotal2-ttotal1))%
(1)
其中,Rcpu_usage表示CPU利用率,tidle1和tidle2分別表示時(shí)間段首末時(shí)間點(diǎn)CPU空閑時(shí)間,ttotal1和ttotal2分別表示時(shí)間段首末時(shí)間點(diǎn)CPU總的運(yùn)行時(shí)間。
2)內(nèi)存負(fù)載的獲取
內(nèi)存負(fù)載的獲取與CPU負(fù)載的獲取類似。/proc/meminfo文件中記錄著系統(tǒng)實(shí)時(shí)的內(nèi)存狀態(tài)信息,相比于CPU信息,其不存在多核的情況:
memtotal:32865856 kB
memtree:20881780 kB
……
內(nèi)存利用率通過式(2)計(jì)算:
Rmem_usage=((mtotal-mfree)×100/mtotal)%
(2)
其中,Rmem_usage表示內(nèi)存的使用率,mtotal表示內(nèi)存總的大小,mfree表示空閑內(nèi)存的大小。
3)系統(tǒng)時(shí)間的獲取
在Linux系統(tǒng)中,通過time函數(shù)可以得到自1970年1月1日00∶00∶00(格林威治時(shí)間)以來的秒數(shù)。對于得到的時(shí)間信息,可以再通過ctime函數(shù)換算成日常所使用的日期時(shí)間表示格式,其返回的字符串格式形如“Wed Jun 28 21∶34∶08 2015”,從該字符串中提取出系統(tǒng)當(dāng)前時(shí)間“21∶34∶08”即可。
3.3.2 文件限制條件的配置
策略配置程序是一個(gè)用戶層的控制程序,負(fù)責(zé)對文件的限制條件進(jìn)行查看和設(shè)置。該用戶層控制程序通過調(diào)用inode_setxattr鉤子函數(shù)來設(shè)置文件限制條件,通過該鉤子函數(shù)把環(huán)境屬性值寫到文件inode結(jié)構(gòu)的i_security安全域中。此外,open/close系統(tǒng)調(diào)用函數(shù)執(zhí)行時(shí),控制程序調(diào)用重寫后的file_alloc_security函數(shù),修改或銷毀安全域文件信息。
在Linux系統(tǒng)中,由于地址空間的限制,內(nèi)核代碼和用戶代碼間不能直接調(diào)用和訪問[15],需要額外的方式實(shí)現(xiàn)它們之間的通信。本文原型系統(tǒng)實(shí)現(xiàn)基于proc文件系統(tǒng)和虛擬字符設(shè)備2種方式的系統(tǒng)間模塊的通信方式。
定義一個(gè)虛擬字符設(shè)備作為環(huán)境屬性值的傳遞模塊,用戶控制模塊中的環(huán)境屬性收集程序,每2 s獲取一次環(huán)境屬性值,并以結(jié)構(gòu)體數(shù)據(jù)格式寫入虛擬字符設(shè)備中。內(nèi)核安全模塊則實(shí)時(shí)地從虛擬字符設(shè)備中讀出環(huán)境屬性值。
內(nèi)核判定模塊中的全局變量,例如內(nèi)核判定模塊是否啟用、主客體的限制條件環(huán)境屬性值等需要提供查詢和修改的接口。本文系統(tǒng)通過在/proc/sys目錄下建立目錄樹以顯示內(nèi)核中保存的全局變量,通過register_sysctl_table函數(shù)實(shí)現(xiàn)。
基于環(huán)境屬性的訪問控制原型系統(tǒng)采用的實(shí)驗(yàn)平臺參數(shù)如表2所示?;谄胀ǖ挠布脚_,增加修改模塊后的操作系統(tǒng),測試訪問控制權(quán)限的動態(tài)性變化情形。
表2 實(shí)驗(yàn)平臺參數(shù)
4.2.1 功能測試
功能測試的目的是驗(yàn)證是否成功將CPU負(fù)載、內(nèi)存負(fù)載以及訪問時(shí)間等環(huán)境屬性值添加到了訪問控制的判定過程中。通過預(yù)先設(shè)置測試文件相關(guān)環(huán)境屬性的限制條件,然后訪問文件,分析對應(yīng)環(huán)境屬性值,判斷文件是否被訪問。
圖4所示為CPU負(fù)載的測試過程,首先,在初始狀態(tài)下被測文件hello設(shè)置為可訪問,經(jīng)測試操作,文件可以進(jìn)行相關(guān)訪問操作。其次,執(zhí)行大數(shù)據(jù)處理的計(jì)算程序,提高當(dāng)前CPU計(jì)算負(fù)載,再次訪問hello文件,訪問被拒絕。最后,當(dāng)結(jié)束高負(fù)載使用CPU的進(jìn)程后,測試文件重新被允許訪問。
圖4 CPU負(fù)載測試
圖5所示為內(nèi)存負(fù)載的測試過程,首先,在初始狀態(tài)下被測文件hello設(shè)置為可訪問,經(jīng)測試操作,文件可以進(jìn)行相關(guān)訪問操作。其次,并行執(zhí)行高內(nèi)存負(fù)載的程序upmem,該程序分配1 GB的內(nèi)存,在休眠5 min(模擬upmem執(zhí)行時(shí)間)后訪問hello文件,訪問被拒絕。最后,結(jié)束upmem程序運(yùn)行,測試文件hello重新被允許訪問。
圖5 內(nèi)存負(fù)載測試
實(shí)驗(yàn)結(jié)果表明,當(dāng)CPU、內(nèi)存等環(huán)境屬性的變化導(dǎo)致系統(tǒng)運(yùn)行存在擁塞等情形中,自適應(yīng)地調(diào)整文件的訪問權(quán)限,能有效優(yōu)化系統(tǒng)服務(wù)。
4.2.2 性能測試
性能測試的目的是為了驗(yàn)證內(nèi)核判定模塊的添加對文件訪問效率的影響程度。采用的測試方法是通過運(yùn)行百萬級的文件訪問,記錄對比在不同測試條件下訪問文件的時(shí)間。測試中選取3種不同的運(yùn)行環(huán)境以及3種不同的測試文件作為前提,分別如表3和表4所示。
表3 模塊測試條件
表4 文件測試條件
如表3和表4所示,本文實(shí)驗(yàn)設(shè)置了3種模塊測試條件,并將對小文件和大文件的文件限制也分成了不同的3種限制條件,目的是為了通過多種測試條件的組合,充分反映內(nèi)核判定模塊的添加對文件訪問效率的影響。每一種測試條件下的文件操作都執(zhí)行了二百萬次,且在每種測試條件都執(zhí)行了3次,最終的測試結(jié)果為3次的平均值。
表5~表7中的測試數(shù)據(jù)記錄是訪問文件三百萬次的時(shí)間,分別統(tǒng)計(jì)了在未對測試文件設(shè)置限制條件、設(shè)置了限制條件但未開啟以及設(shè)置了限制條件且開啟3種情況下,對小、大文件進(jìn)行打開、讀和寫操作的時(shí)間。從實(shí)驗(yàn)數(shù)據(jù)可以看出,在添加和未添加內(nèi)核判定模塊的不同情況下,對文件訪問操作的耗時(shí)并沒有出現(xiàn)大的起伏,同時(shí)考慮到系統(tǒng)實(shí)時(shí)運(yùn)行環(huán)境因素對測試的影響以及誤差的存在,可以說明內(nèi)核判定模塊對文件訪問效率影響很小。通過實(shí)驗(yàn)數(shù)據(jù)可以得出結(jié)論,該訪問控制原型系統(tǒng)所執(zhí)行的訪問控制效率較高,不會影響到系統(tǒng)的正常運(yùn)行,同時(shí)具備了較高的安全性和可用性。
表5 打開操作的訪問時(shí)間 s
表6 讀操作的訪問時(shí)間 s
表7 寫操作的訪問時(shí)間 s
本文構(gòu)建一種基于環(huán)境屬性的訪問控制模型EABAC,以豐富Linux平臺中的訪問控制機(jī)制。該模型將系統(tǒng)的環(huán)境屬性加入到訪問判定的過程中,擴(kuò)展了Linux訪問控制策略的范圍。同時(shí)基于EABAC模型開發(fā)Linux平臺下的訪問控制原型系統(tǒng)。實(shí)驗(yàn)結(jié)果表明,該系統(tǒng)考慮內(nèi)核空間和用戶空間程序的運(yùn)行效率,基于LSM框架實(shí)現(xiàn)內(nèi)核判定模塊,具有良好的通用性和可擴(kuò)展性;在用戶空間為用戶提供友好的控制接口,實(shí)現(xiàn)策略的自定義配置。下一步將把更多的環(huán)境屬性加入到安全模塊中,添加系統(tǒng)日志等功能,方便系統(tǒng)管理員的審計(jì)工作。
[1] 李鳳華,蘇 芒,史國振,等.訪問控制模型研究進(jìn)展及發(fā)展趨勢[J].電子學(xué)報(bào),2012,40(4):805-813.
[2] 王小明,付 紅,張立臣.基于屬性的訪問控制研究進(jìn)展[J].電子學(xué)報(bào),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].通信學(xué)報(bào),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ìn)展[J].計(jì)算機(jī)科學(xué),2010,11(7):84-87.
[9] 吳新松,賀也平,周洲儀.一個(gè)環(huán)境適應(yīng)的基于角色的訪問控制模型[J].計(jì)算機(jī)研究與發(fā)展,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權(quán)限訪問控制模型[J].小型微型計(jì)算機(jī)系統(tǒng),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.