Docker容器逃逸防護(hù)技術(shù)研究

胥 柯 張新有 栗曉晗

(西南交通大學(xué)計算機(jī)與人工智能學(xué)院 成都 611756)

隨著容器技術(shù)的持續(xù)升溫，其安全問題也備受關(guān)注.比如鏡像安全問題[1]、容器逃逸、拒絕服務(wù)攻擊[2]等.Docker的使用愈發(fā)廣泛，容器逃逸安全加固手段卻十分匱乏，若不對其安全逃逸問題加以重視，一旦發(fā)生逃逸將會造成嚴(yán)重后果[3].

本文從訪問控制的角度出發(fā)，限制用戶的操作權(quán)限，提高容器間的隔離性，可切實(shí)縮小逃逸后攻擊者的訪問權(quán)限，降低其帶來的危害.但傳統(tǒng)的強(qiáng)制訪問控制(mandatory access control, MAC)系統(tǒng)主/客體的安全等級可能存在難確立且含有過多主觀因素的干擾.本文結(jié)合模糊聚類分析與風(fēng)險矩陣分析，采用客觀真實(shí)的數(shù)據(jù)對主客體進(jìn)行安全等級劃分.并與MAC相結(jié)合，提出一種針對Docker容器逃逸加固的多級模糊安全訪問模型CFMAC，并利用LSM技術(shù)進(jìn)行實(shí)現(xiàn).

1 研究現(xiàn)狀

Docker孵化至今，經(jīng)歷了8年的發(fā)展.隨著其廣泛應(yīng)用，安全問題也開始引人關(guān)注，國內(nèi)外研究人員開始致力于Docker安全研究，分析它的攻擊面以及研究安全加固方案.

王娟等人[4]針對非授權(quán)通信等問題，提出使用可信計算提高容器的安全性.主要使用信任鏈與完整性度量，通過構(gòu)造容器內(nèi)部到文件的完整信任鏈，設(shè)計實(shí)現(xiàn)了安全性更高的Docker容器.該方法主要針對單一容器，保證鏡像等文件不被篡改，但不適應(yīng)集群環(huán)境.馬小淋[5]提出一種基于負(fù)載特征的容器云彈性伸縮策略，減少了暫行性負(fù)載增減造成的伸縮抖動.李平平等人[6]提出基于LSM的Docker訪問控制機(jī)制，為Docker容器逃逸防護(hù)提供了可能，但是提出的方案也未結(jié)合實(shí)際的生產(chǎn)環(huán)境，不能應(yīng)用至集群.

Red Hat的Docker安全的總負(fù)責(zé)人Walsh[7]提出可通過更加細(xì)粒度的權(quán)限分配和訪問控制系統(tǒng)對Docker容器進(jìn)行加固.陳莉君等人[8]認(rèn)為容器的部分安全問題來自于隔離性的不足，采用分層設(shè)計實(shí)現(xiàn)容器資源隔離系統(tǒng)，具有良好的性能.但是并未對宿主機(jī)關(guān)鍵文件以及容器共享出的文件進(jìn)行隔離，一旦逃逸發(fā)生就會對宿主機(jī)關(guān)鍵文件進(jìn)行修改，危及宿主機(jī)和容器的安全，嚴(yán)重時可能導(dǎo)致服務(wù)失效.

也不乏一些前輩從性能資源監(jiān)控的角度出發(fā)，設(shè)計監(jiān)控警報系統(tǒng)，讓安全管理員及時作出應(yīng)對措施，時至今日，這些監(jiān)控技術(shù)已經(jīng)漸進(jìn)成熟.Dhakate等人[9]認(rèn)為為了自動化云服務(wù)的整個測試過程，應(yīng)該有一種精確的實(shí)現(xiàn)方式，使其在底層基礎(chǔ)設(shè)施更改期間更加穩(wěn)定和可接受，于是設(shè)計了一種集監(jiān)控與智能警報于一體的輕量級分布式云平臺監(jiān)控系統(tǒng)，并提出在未來實(shí)現(xiàn)自動修復(fù)的可能.Salvatore[10]認(rèn)為監(jiān)控系統(tǒng)應(yīng)呈現(xiàn)給用戶簡潔、智能、友好的交互窗口，盡可能降低用戶的操作復(fù)雜度，同時監(jiān)控系統(tǒng)也應(yīng)在分布式的大環(huán)境下適應(yīng)容器生命周期的快速變更.

目前，市場上存在一些監(jiān)控軟件，例如DataDog,Grafana,Prometheus等[11]，這些大都提供再開發(fā)的功能，使用難度也參差不齊，都是對內(nèi)存、流量、CPU占用率等數(shù)據(jù)進(jìn)行監(jiān)控，缺乏對Docker容器逃逸等攻擊的針對性監(jiān)控.

上述對Docker的安全性分析與安全加固研究，都在一定程度上從Docker易受攻擊的角度，包括倉庫鏡像與遠(yuǎn)程連接、拒絕服務(wù)攻擊、權(quán)限分配等，提升Docker的安全性.但是針對Docker容器逃逸的防護(hù)措施匱乏，這是因為容器逃逸方式多變、誘因各異所致.本文從限制容器逃逸后的訪問權(quán)限出發(fā)與強(qiáng)制訪問控制相結(jié)合，盡可能保證核心文件的安全，從而達(dá)到提升Docker容器安全性的目的.

2 相關(guān)技術(shù)

2.1 MAC

MAC系統(tǒng)主要包括主體、客體與訪問控制策略[6].客體一般為需要保護(hù)的對象或者需要進(jìn)行訪問控制的對象，而主體即為向客體發(fā)起訪問的對象，通常來說為進(jìn)程.在CFMAC模型中，主體即為容器.主體和客體各自具有獨(dú)立的安全屬性，且安全屬性的設(shè)置權(quán)限為管理員所持有，不能隨意更改.無論主體對客體的何種操作都將必須執(zhí)行訪問控制策略，判斷操作是否允許[12].

MAC通過無法避免的存取限制來阻止直接或間接的非法入侵[13].有許多安全敏感的系統(tǒng)，如軍事部門、政府、銀行等，這些部門的資源通常按照安全級別進(jìn)行分區(qū)，而整個系統(tǒng)使用嚴(yán)格的MAC來保持?jǐn)?shù)據(jù)的機(jī)密性和完整性.Bell-Lapadula模型是David Bell和Leonard LaPadula為模仿軍事安全政策而提出的一種計算機(jī)安全模型，在高安全性系統(tǒng)中得到了廣泛的應(yīng)用和研究，如SELinux和數(shù)據(jù)庫安全系統(tǒng).

2.2 命名空間

命名空間(Namespaces)是Linux對全局系統(tǒng)資源的一種封裝及安全隔離方法.通過Namespace進(jìn)程只能看到與自己相關(guān)的資源，進(jìn)程之間感覺不到對方的存在.具體的實(shí)現(xiàn)方式是把1個或多個進(jìn)程的相關(guān)資源指定在同一個Namespace中.

當(dāng)進(jìn)行Linux應(yīng)用開發(fā)時，對需要的Namespace類型進(jìn)行聲明，就可以實(shí)現(xiàn)對應(yīng)的資源類型隔離.Namespace是Linux容器技術(shù)的基礎(chǔ).Linux內(nèi)核支持6種不同的Namespace，如表1所示：

表1 Linux Namespace

由表1可知PID,IPC,Network等資源屬于某個特定的Namespace，不再是全局變量，Namespace之間相互獨(dú)立.Namespace定義請參見文獻(xiàn)[14].1個Namespace可以產(chǎn)生多個子Namespace.運(yùn)用Kernel中的Namespace機(jī)制和Cgroup機(jī)制實(shí)現(xiàn)輕量級的虛擬，多個虛擬容器共用宿主機(jī)的Kernel，彼此之間資源隔離.Docker也正是依賴于此[16].

3 總體設(shè)計

使用模糊聚類對MAC的安全等級進(jìn)行劃分，減少主觀因素的影響，使分級更加規(guī)范科學(xué).針對Docker的實(shí)際應(yīng)用情況，改良傳統(tǒng)MAC模型，對Docker進(jìn)行安全加固，從而降低逃逸后攻擊者對系統(tǒng)帶來的危害.

3.1 主客體及安全等級劃分

CFMAC模型屬于強(qiáng)制訪問控制的范疇，對于訪問控制系統(tǒng)設(shè)計、訪問控制的3個要素(主體、客體、控制策略)必須有清楚的定義.在主體劃分方面，定義容器Ci(1≤i≤v，i為正整數(shù)，v為當(dāng)前宿主機(jī)存在的容器個數(shù))為主體，包含容器內(nèi)所有子進(jìn)程；在客體劃分方面，將容器將要訪問的文件定義為客體，根據(jù)文件的直接歸屬不同，主要分為3類.分別定義為：宿主機(jī)系統(tǒng)關(guān)鍵路徑文件HF；Docker容器i與j共享數(shù)據(jù)卷文件SF{i,j}(1≤i≠j≤v，i，j為正整數(shù)，v為當(dāng)前宿主機(jī)存在的容器個數(shù))，也即在創(chuàng)建共享數(shù)據(jù)卷容器時所使用的參數(shù)；Docker容器Ci的直接相關(guān)文件即容器創(chuàng)建后overlay2下的容器運(yùn)行所依賴文件CFi.

目標(biāo)將主、客體分為3類.設(shè)待分類樣本集合為X={x1，x2，…，xi，…，xn}，n為樣本個數(shù)，本文系統(tǒng)將上述主、客體設(shè)置為樣本集合.每個獨(dú)立的樣本包含m個統(tǒng)計指標(biāo)，xik表示第i個樣本的第k個指標(biāo).統(tǒng)計指標(biāo)反映最終的準(zhǔn)確程度，是取得合理聚類的首要條件.依據(jù)風(fēng)險等級評級方法中的風(fēng)險矩陣分析法，RK=L·S，其中RK是風(fēng)險值，是事故發(fā)生的可能性與事件后果嚴(yán)重性的綜合指標(biāo)，L是事故發(fā)生的可能性，S是事故后果的嚴(yán)重性，RK值越大，說明該文件被攻擊者訪問對系統(tǒng)危險性越大，相對應(yīng)的安全等級也應(yīng)設(shè)置較高[17].同時參照Docker容器逃逸的實(shí)際應(yīng)用場景，現(xiàn)選取2個具有實(shí)際意義的指標(biāo)，將事故發(fā)生的可能性L設(shè)置為引發(fā)容器安全問題的安全漏洞個數(shù)，用P表示，將事故后果的嚴(yán)重性S設(shè)置為安全問題帶來的直接經(jīng)濟(jì)損失，用M(元)表示：

1) 安全漏洞個數(shù)P.數(shù)據(jù)來源于由Sysdig公司所提供的最近年度容器安全現(xiàn)狀分析[18].

2) 逃逸損失M.M反映該目錄文件若被攻擊者獲取造成的財產(chǎn)損失額.設(shè)每個與Docker容器相關(guān)文件所帶來的損失為單位1，Ci的損失為CFi與SF{i,j}之和，HF損失值即宿主機(jī)關(guān)鍵路徑文件帶來的損失.宿主機(jī)關(guān)鍵路徑文件會對系統(tǒng)安全帶來一定影響，若容器逃逸至宿主機(jī)，那么該宿主機(jī)上的所有容器都將無法使用，故HF的損失值估計為宿主機(jī)上所有容器損失之和.根據(jù)Kubernetes1.2更新日志中的說明，推薦1臺機(jī)器部署3個Pod.結(jié)合當(dāng)下時速云公司的生產(chǎn)環(huán)境中平均每個Pod約有2～3個Docker容器，取折中2.5個，所以HF的損失值約為單個容器逃逸損失的750%.

上述2個指標(biāo)的核心參數(shù)統(tǒng)計結(jié)果如表2所示：

表2 核心參數(shù)統(tǒng)計結(jié)果

將上述數(shù)據(jù)處理得到原始數(shù)據(jù)矩陣T，第1列值為相關(guān)安全漏洞數(shù)，第2列值為容器逃逸損失.

(1)

采用最大值標(biāo)準(zhǔn)化方法將T標(biāo)準(zhǔn)化，使值全部在[0,1]的區(qū)間范圍內(nèi)Y，Y為T的標(biāo)準(zhǔn)化處理結(jié)果.

(2)

(3)

用傳遞閉包求R的模糊等價矩陣.傳遞閉包是包含R的最小傳遞矩陣，采用平方法求R的傳遞閉包V：

(4)

模糊等價矩陣V按α截關(guān)系對其進(jìn)行聚類，V的α截矩陣為V=(αrij)n×m，其中:

(5)

對于不同的α截矩陣，分類結(jié)果不同其實(shí)際意義和經(jīng)濟(jì)意義也不同，從中可判斷出與實(shí)際最接近的分類方案.當(dāng)α<μ時，Rα的分類是Rμ的加細(xì)，當(dāng)α由1變?yōu)?時，Rα的分類由細(xì)變粗，形成一個動態(tài)聚類圖，如圖1所示：

圖1 動態(tài)聚類圖

當(dāng)0<α≤0.227 1時，得到的分類是{Ci,CFi,SF{i,j},HF};

當(dāng)0.227 1<α≤0.650 0時，得到的分類是{Ci,CFi,SF{i,j}}{HF};

當(dāng)0.650 0<α≤0.893 3時，得到的分類是{CFi,Ci}{SF{i,j}}{HF};

當(dāng)0.893 3<α≤1時，得到的分類是{CFi}{Ci}{SF{i,j}}{HF}.

根據(jù)實(shí)際需要目標(biāo)分類是主、客體分為3類，記作{CFi,Ci}{SF{i,j}}{HF}.且依據(jù)統(tǒng)計量F確定最佳α值，也分類為{CFi,Ci}{SF{i,j}}{HF}.

統(tǒng)計量F的計算公式為

(6)

其中,

(7)

(8)

式(6)中分子表示分類與分類之間的距離，分母表示分類內(nèi)樣本間的距離.因此，F(xiàn)值越大，說明類與類之間的距離越大，類與類間的差異越大，分類就越好.計算得到最優(yōu)分類為{CFi,Ci}{SF{i,j}}{HF}，F(xiàn)值最大約為185.360 7.

依據(jù)風(fēng)險值RK作輔助評判，因為HF>Ci>CFi>SF{i,j}，故安全等級設(shè)置為HF>CFi=Ci>SF{i,j}，與構(gòu)想安全等級設(shè)置一致.將安全等級設(shè)置為secret>general>public.

3.2 HF,CFi訪問控制

CFMAC系統(tǒng)啟動之前，需要對訪問控制的主客體進(jìn)行安全屬性設(shè)置.然而宿主機(jī)內(nèi)文件繁雜眾多，若以文件為單位進(jìn)行安全屬性的設(shè)置，工作量會十分龐大，故考慮從目錄的角度出發(fā)，系統(tǒng)對宿主機(jī)文件進(jìn)行訪問時按照配置文件的目錄配置信息進(jìn)行訪問控制.

當(dāng)某個進(jìn)程發(fā)起訪問時，首先對進(jìn)程源進(jìn)行判定，通過對PID chain的識別判斷是否為容器進(jìn)程，CFMAC只針對容器進(jìn)程的訪問控制.其次對文件進(jìn)行定位，獲取文件的安全信息，對主客體進(jìn)行安全等級判斷，決定是否可以進(jìn)行訪問.因為PID Namespace的存在，使得子進(jìn)程在父進(jìn)程的Namespace下進(jìn)行活動，所以在Linux中所有的進(jìn)程都有1個共同的父進(jìn)程為0號進(jìn)程，同理，Docker中的所有進(jìn)程都在Docker Daemon的范圍下進(jìn)行活動，進(jìn)行PID溯源操作，得到PID chain便可判斷當(dāng)前正在執(zhí)行進(jìn)程是否為Docker相關(guān)進(jìn)程.

圖2顯示了容器進(jìn)程隔離模塊的設(shè)計目標(biāo).對于單個容器范圍內(nèi)的文件訪問嚴(yán)格遵守安全等級限制；對于多容器范圍，對CF不允許跨容器訪問，從而實(shí)現(xiàn)容器間相互隔離.

圖2 容器進(jìn)程訪問CFi和HF

3.3 SF{i,j}訪問控制

針對Pod內(nèi)容器對SF{i,j}的訪問，需對共享文件進(jìn)行信息記錄，包括路徑、Pod名以及參與共享的容器.在同Pod內(nèi)若某個容器沒有主動將某文件共享，則當(dāng)容器逃逸后對SF{i,j}也沒有訪問權(quán)限.圖3清楚地反映了訪問控制情況.對于同Pod而言，容器C2,C4不能訪問SF{1,3},同樣容器C1也對SF{2,3,4}沒有訪問權(quán)限.對于異Pod而言，Pod1內(nèi)有4個容器C1,C2,C3,C4，不可訪問Pod2中SF{5,6}.同樣Pod2中容器C5，C6也不能訪問Pod1中的任意SF{i,j}，即SF{1,3}，SF{2,3,4}.

圖3 容器進(jìn)程訪問SF{i,j}

4 系統(tǒng)功能的實(shí)現(xiàn)

本節(jié)介紹CFMAC的實(shí)現(xiàn)過程，包括功能架構(gòu)及實(shí)現(xiàn)流程等相關(guān)細(xì)節(jié).圖4為CFMAC模型整體架構(gòu).

4.1 進(jìn)程識別

Linux內(nèi)核使用task_struct數(shù)據(jù)結(jié)構(gòu)來關(guān)聯(lián)所有與進(jìn)程有關(guān)的數(shù)據(jù)和結(jié)構(gòu)，Linux內(nèi)核涉及到進(jìn)程和程序的所有算法都是圍繞該數(shù)據(jù)結(jié)構(gòu)建立的，是內(nèi)核中最重要的數(shù)據(jù)結(jié)構(gòu)之一.

利用內(nèi)核中指向當(dāng)前進(jìn)程的current指針，獲取正在執(zhí)行訪問任務(wù)進(jìn)程的PID.根據(jù)獲取到的PID，獲得完整的PID chain，根據(jù)PID chain中的內(nèi)容判斷出是否為Docker 相關(guān)進(jìn)程.進(jìn)程識別流程如圖5所示.

4.2 CFMAC訪問控制

CFMAC通過定義相關(guān)LSM鉤子函數(shù)，實(shí)現(xiàn)對文件訪問控制，主要通過file_open實(shí)現(xiàn).security_hook_list如下：

static structsecurity_hook_list dockerlsm_hooks[]={

LSM_HOOK_INIT(file_open,dockerlsm_file_open)；

…}；

當(dāng)只涉及單容器訪問時，訪問規(guī)則嚴(yán)格遵守安全等級.當(dāng)涉及多容器訪問時，容器進(jìn)程訪問控制流程如下：首先進(jìn)行系統(tǒng)初始化，包括鉤子函數(shù)攔截訪問訪問、配置文件讀取等.然后進(jìn)程識別，若是容器相關(guān)進(jìn)程執(zhí)行目標(biāo)文件識別，否則直接結(jié)束允許訪問.識別目標(biāo)文件，獲取目標(biāo)文件來源，判定文件類型HF,CFi,SF{i,j}.主客體安全等級判斷：若文件為HF則拒絕訪問；若為CFi，判斷文件與進(jìn)程安全標(biāo)簽是否一致，若一致且訪問的是CFi則允許訪問，否則拒絕訪問；若為SF{i,j}，則判斷Pod是否一致，若一致則進(jìn)行Pod內(nèi)id大小判斷，若主體id大于等于客體id允許訪問，否則拒絕訪問.

圖4 CFMAC模型整體架構(gòu)

圖5 進(jìn)程識別流程

4.3 文件識別

為提高系統(tǒng)效率，先對靶向文件進(jìn)行識別，若為HF,CF,SF中的某一類文件再進(jìn)行訪問控制.對HF,CF,SF文件進(jìn)行安全標(biāo)簽填充，即比普通文件多1個security.cfmac的擴(kuò)展屬性.首先判斷擴(kuò)展屬性security.cfmac值是否為空，若不為空則執(zhí)行安全等級校驗，若為空則進(jìn)行有無父inode節(jié)點(diǎn)判斷.

因為CF,SF的文件眾多，若逐一設(shè)置安全標(biāo)簽則會給安全管理員帶來很多負(fù)擔(dān).為提高管理員的工作效率，最終選擇將安全標(biāo)簽貼至總目錄上，這樣可以避免對每個文件設(shè)置安全標(biāo)簽.故文件識別時直到無父inode或者安全擴(kuò)展屬性不為空為止.若一直為空，則不為HF,CF,SF中的某一類文件，則允許訪問.一旦出現(xiàn)security.cfmac不為空，則一定為HF,CF或SF中的某一類文件，則需要進(jìn)一步作安全訪問控制校驗.

在用戶態(tài)使用setfattr命令為文件設(shè)置擴(kuò)展屬性，-n參數(shù)后接上key值進(jìn)行設(shè)置.在內(nèi)核態(tài)利用inode節(jié)點(diǎn)中的getxattr操作進(jìn)行擴(kuò)展屬性獲取.單個文件識別流程如圖6所示.首先獲取當(dāng)前訪問file的結(jié)構(gòu)體信息，然后使用getxattr獲得擴(kuò)展屬性security.cfmac得到值，若為空則進(jìn)行有無父inode判斷，當(dāng)存在父inode時，則該文件仍保留為CF或SF的可能，故需要一直向上取父inode，直到不存在父inode時則所有可能性都進(jìn)行了安全標(biāo)簽的判斷.若最后無父inode且安全標(biāo)簽也一直為空，則這個文件只是普通文件，不會對系統(tǒng)或Docker容器帶來危害，則可以直接放行.一旦擴(kuò)展屬性security.cfmacy有值，則說明文件為HF，CF或SF中的某一類，需要進(jìn)行強(qiáng)制訪問控制.

圖6 單個文件識別流程

5 模型測試

本節(jié)對CFMAC模型進(jìn)行測試，分別設(shè)置單容器、同Pod多容器、多Pod多容器對SF{i,j}，CFi，HF的訪問效果進(jìn)行測試.測試目標(biāo)包括：1)單容器下嚴(yán)格遵守安全等級總則進(jìn)行訪問，Ci只可訪問CFi及SF{i,j}，不可訪問HF；2)容器間不可自由訪問彼此的CF文件；3)Pod內(nèi)id相對大的可訪問Pod內(nèi)id相對小的SF{i,j}文件；4)Pod之間不可自由訪問SF{i,j}文件.根據(jù)上述測試目標(biāo)及實(shí)際逃逸模擬情況，為方便進(jìn)行測試給出如下測試方式.

5.1 測試環(huán)境

宿主機(jī)環(huán)境：操作系統(tǒng)Centos 7，Linux內(nèi)核版本4.5.4，Docker版本1.14.1；容器環(huán)境：鏡像Ubuntu15.10，Linux內(nèi)核版本4.5.4.

容器間網(wǎng)絡(luò)配置使用Docker默認(rèn)配置，各容器共享宿主機(jī)網(wǎng)絡(luò)，彼此間相互隔離.模擬逃逸利用Docker共享數(shù)據(jù)卷功能實(shí)現(xiàn).

5.2 測試方案

5.2.1 單容器訪問測試

1) 將宿主機(jī)HF掛載至Docker容器內(nèi)，用來測試單容器下Ci訪問HF.在容器內(nèi)對宿主機(jī)/root目錄發(fā)起訪問，測試結(jié)果如圖7所示，使用cat命令對文件進(jìn)行查看，cat會自動將文件參數(shù)識別為無效參數(shù)，從而無法打開文件.超出容器范圍進(jìn)行訪問，進(jìn)程將會被識別為逃逸程序，觸發(fā)訪問控制程序，限制容器內(nèi)發(fā)起的訪問，CFMAC在內(nèi)核中的運(yùn)行效果如圖8所示.

圖7 單容器訪問HF

圖8 內(nèi)核運(yùn)行CFMAC效果

2) 掛載1個普通數(shù)據(jù)卷至Docker容器內(nèi)，測試單容器下Ci訪問SF{i,j}.在容器內(nèi)對/usr目錄發(fā)起訪問，可自由查看文件內(nèi)容，測試結(jié)果如圖9所示：

圖9 單容器訪問SF{i,j}

3)CFi訪問測試不用另行創(chuàng)建容器，可直接利用上述創(chuàng)建的2個容器進(jìn)行測試.測試結(jié)果如圖10所示，可自由查看自己容器內(nèi)文件.

圖10 單容器訪問CFi

5.2.2 同Pod多容器訪問測試

1) 創(chuàng)建容器volumetest05，將宿主機(jī)中/var/lib/Docker中其他容器所屬文件，掛載至volumetest05，用于測試跨容器訪問CF文件.結(jié)果如圖11所示：

圖11 跨容器訪問CFi

2) 基礎(chǔ)容器創(chuàng)建docker run -it -v /data --name=test -d ubuntu:15.10；將容器test中創(chuàng)建的共享數(shù)據(jù)卷/data掛載至容器sfvolumetest01，sfvolumetest02，并在配置文件中設(shè)置為Pod1，用于測試同Pod多容器間訪問SF{i,j}文件.同Pod容器中訪問SF文件，id相對小者禁止訪問由id相對大者共享的SF{i,j}文件.反之則允許訪問.測試結(jié)果如圖12、圖13所示：

圖12 容器Pod內(nèi)id小者訪問SF{i,j}

圖13 容器Pod內(nèi)id大者訪問SF{i,j}

5.2.3 異Pod多容器訪問測試

異Pod容器創(chuàng)建，配置文件中設(shè)置sfvolume03容器group為2，id為0.測試異Pod訪問SF，測試結(jié)果如圖14所示，禁止跨Pod訪問SF.

上述異Pod容器創(chuàng)建情況(部分)如圖15所示：

圖15 異Pod容器創(chuàng)建情況

5.2.4 性能測試

安全加固方案的性能也是十分重要的，不能為了安全而過分地舍棄性能，本文方案對Docker的源碼未作任何修改，故對Docker的性能不會帶來大的影響.所以只對Linux系統(tǒng)性能進(jìn)行測試，現(xiàn)對加載了CFMAC模型內(nèi)核的系統(tǒng)和未加載的原始系統(tǒng)作對比測試實(shí)驗.測試方法是分別在2種環(huán)境下讓UnixBench執(zhí)行10次，對UnixBench給出的Index Score取均值.

從圖16的數(shù)據(jù)可知，綜合性能損失約為14.97個“George”基線系統(tǒng).CFMAC對系統(tǒng)的性能影響較小.

圖16 UnixBench性能測試結(jié)果

6 結(jié)束語

本文從實(shí)際生產(chǎn)應(yīng)用環(huán)境出發(fā)，為防止容器逃逸帶來巨大損失，提出CFMAC模型對Docker容器進(jìn)行安全加固.CFMAC是一個基于Docker的強(qiáng)制訪問控制模型.該模型從結(jié)構(gòu)上對傳統(tǒng)安全模型進(jìn)行修改，結(jié)合模糊聚類進(jìn)行安全等級劃分.利用LSM技術(shù)，對file_open進(jìn)行訪問攔截實(shí)現(xiàn).測試結(jié)果達(dá)到預(yù)期目標(biāo)，表明CFMAC能有效進(jìn)行安全加固，對用戶文件操作進(jìn)行訪問控制，達(dá)到最小化權(quán)限限制[19].在下一步的工作中，將模型進(jìn)行調(diào)整使其貼合實(shí)際集群應(yīng)用環(huán)境，對其他權(quán)限也進(jìn)行限制.