色爱综合区,亚洲中文字幕黄网站,国产三级在线播放欧美,美国一级毛片aa,av无码,天天干,婷婷六月丁香91视频,免费的黄色网站4mmb

<source id="3zixk"><tr id="3zixk"></tr></source>

會員中心
加入VIP
微信

客服微信網(wǎng)站公眾號

　煤礦　化工　建筑
　機械　電力　冶金
　消防　交通　特種

　論壇　活動　視頻
　問答　投稿　 MSDS
　簽到　超市　招聘

導航：安全管理網(wǎng)>> 安全論文>> 交通安全論文>>正文

操作系統(tǒng)安全測評及安全測試自動化的研究

文檔作者：陳晨		點擊數(shù)：	更新時間： 2021年07月13日
下載地址：點擊這里	文件大?。?4.24 MB 共80頁	文檔格式： PDF	下載點數(shù)： 1 點（VIP免費）

部分內(nèi)容預覽 [文件共80頁]

本文件共80頁，只能預覽部分內(nèi)容，查看全部內(nèi)容需要下載。

注：預覽效果可能會出現(xiàn)部分文字亂碼（如口口口）、內(nèi)容顯示不全等問題，下載是正常的。

	文件大小：4.24 MB 共80頁文件格式：PDF 下載點數(shù)：1 點（VIP會員免費）

下一篇：論管道企業(yè)的車輛安全管理

上一篇：車輛載荷碾壓作用下管道的安全性測試與分析

文本預覽

僅提取頁面文字內(nèi)容，供快速閱讀使用。

北京交通大學
碩士學位論文
操作系統(tǒng)安全測評及安全測試自動化的研究
姓名：陳晨
申請學位級別：碩士
專業(yè)：計算機軟件與理論
指導教師：翟高壽
20080601
摘要
摘要
隨著計算機與網(wǎng)絡技術(shù)的普及應用，信息安全已經(jīng)成為關(guān)系到國家安全的關(guān)
鍵因素。操作系統(tǒng)是整個信息系統(tǒng)安全的基礎，如果不經(jīng)過安全測評，操作系統(tǒng)
的安全性就得不到保障。而且隨著我國操作系統(tǒng)研發(fā)的不斷發(fā)展，設計出有效的
安全測評自動化工具已成為迫切的需求。
為了實現(xiàn)操作系統(tǒng)安全測評自動化，首先要對操作系統(tǒng)安全測評方法進行研
究，而信息安全測評標準在一定程度上體現(xiàn)了安全操作系統(tǒng)測評方法的基本思想。
本文概述了現(xiàn)有的安全測評標準，并且對現(xiàn)階段最完善的CC安全測評體系做了詳
細分析，得出了CC安全體系測評方法實施的基本要領和測評流程。
本文在操作系統(tǒng)安全測評自動化的研究中，分析了國內(nèi)現(xiàn)有的安全測評自動
化系統(tǒng)的設計方案，并在吸取了其優(yōu)點和融合了軟件測試自動化方法的基礎上，
給出了改進后的操作系統(tǒng)安全測評自動化框架以及其中的技術(shù)難點和可能的解決
方案。
操作系統(tǒng)的安全測試是其安全測評的基礎和關(guān)鍵環(huán)節(jié)，而操作系統(tǒng)安全測試
自動化系統(tǒng)本身就是一個龐大的系統(tǒng)。鑒于訪問控制機制是操作系統(tǒng)最為關(guān)鍵的
安全支撐機制，同時國內(nèi)自主研發(fā)的操作系統(tǒng)多基于Linux內(nèi)核，所以本文以Linux
系統(tǒng)的訪問控制機制為切入點，對操作系統(tǒng)安全測試自動化進行了探索和討論，
并設計和實現(xiàn)了Linux訪問控制安全測試自動化工具。該工具可基于手動編制的用
例轉(zhuǎn)化規(guī)則，自動執(zhí)行XML語言描述的特定格式的訪問控制測試用例，判斷測試
結(jié)果，并給出測試報告。論文還給出了對該測試自動化工具的討論。
論文最后對課題研究工作進行了總結(jié)，并指出了改進的方向。
關(guān)鍵詞：操作系統(tǒng)；安全測評；安全測試自動化；Linux
分類號：TP316；TP309
ABSTRACT
Along with the widespread application of computer and network technology,
information security has become a key factor of national security．And the security of
entire information system is based on that of operating system．The evaluation of the
operating system Can assure that the security function fulfill their security needs．And as
the domestic development of operating system，design and implementation of the
automated security evaluation tools has become an urgent request．
To achieve the security evaluation automation，first we should study on the
evaluation methods of it．To a certain extent，the security evaluation methods are
expressed by the security evaluation cirterias，SO most of the secudy evaluation cirterias
have been introduced．In addition，the architecture of CC and the three documents of it
have been analysed，which has been recognized as the most developed criteria for
security evaluation．The principle of the CC security evaluation method and process of
the evaluation has been summarized．
In the study of achieving the automated security evaluation，two domestic typical
models of automated security evaluation system have been analysed．The design of an
improved security evaluation framework is given by learning from their advantages and
integrating of automated software testing methods，while related technical problems and
possible solutions are discussed．
Undoubtedly security evaluation is a key step for security evaluation，and the
automated security test system for an operating system huge system itself．Meanwhile
access control is an important component of operating systems．Moreover，the Linux
kernel is widely used by most research institutes and development teams．Therefore，
security test for Linux access control is focused on in our reseach．An automated
security test tool for Linux access control is designed and implemented．It can execute
the test cases，judge the running results of the test cases and provide test reports
automatically．All test cases should be writtern in special XML and they can be
translated into test command flows with mannually written rules．Elementary tests are
performed for the toll and the results are satisfactory．Finally,research works in this
dissertation are summarized and the future WOrks are discussed．
KEYWORDS：Operating System；Security Evaluation；Automated Security Test；Linux
CLASSN0：TP316：TP309
學位論文版權(quán)使用授權(quán)書
本學位論文作者完全了解北京交通大學有關(guān)保留、使用學位論文的規(guī)定。特
授權(quán)北京交通大學可以將學位論文的全部或部分內(nèi)容編入有關(guān)數(shù)據(jù)庫進行檢索，
并采用影印、縮印或掃描等復制手段保存、匯編以供查閱和借閱。同意學校向國
家有關(guān)部門或機構(gòu)送交論文的復印件和磁盤。
(保密的學位論文在解密后適用本授權(quán)說明)
學位論文作者簽名：爵缸導師簽名：翟南壽
簽字日期：硎男年占月‘日簽字日期： 湘8年多月莎Et
獨創(chuàng)性聲明
獨創(chuàng)性聲明
本人聲明所呈交的學位論文是本人在導師指導下進行的研究工作和取得的研
究成果，除了文中特別加以標注和致謝之處外，論文中不包含其他人已經(jīng)發(fā)表或
撰寫過的研究成果，也不包含為獲得北京交通大學或其他教育機構(gòu)的學位或證書
而使用過的材料。與我一同工作的同志對本研究所做的任何貢獻均已在論文中作
了明確的說明并表示了謝意。
學位論文作者簽名： 侍崧IIIii=IIII：娜8年石月多日
75
致謝
在論文完成之際，謹向我尊敬的導師翟高壽副教授表示由衷的感謝!翟老師以
其廣博的知識、縝密的思維和嚴謹?shù)墓ぷ餮芯孔黠L，在論文選題和整個寫作過程
中都給了我精心的指導和幫助，我的論文中凝聚了他大量的心血和汗水。翟老師
從學習上、生活上都給予了我無私的關(guān)懷，使我不僅學到了專業(yè)知識，還為我今
后的工作乃至人生積累了一筆寶貴的精神財富，使我受益終生!
衷心感謝實驗室的各位同學，在課題進行期間，他們給予了我很多技術(shù)方面
的幫助，同時對我的論文也提出了很多中肯的意見。感謝計算機學院的全體老師，
通過他們辛勤的教誨，使我的學識和素質(zhì)都得到了很大的提高。
感謝所有關(guān)心和幫助我的朋友和同學，特別是李耀東、王瑞昌、牛晗暉、張
宇峰、馬文琳等同學在課題研究和論文校對等方面給了我很多幫助，也正是我們
大家的共同探討、相互啟發(fā)、協(xié)同工作，才使課題得以順利進行，并取得今天的
成績。最后，向所有關(guān)心我和幫助我的人表示最誠摯的謝意。
緒論
1．1 論文研究背景與意義
1 緒論
1．1．1信息安全與操作系統(tǒng)安全
隨著計算機與網(wǎng)絡技術(shù)的迅速普及，它們在給人們的工作、生活帶來便捷的
同時，也帶來了信息安全方面的威脅。黑客應運而生，信息安全事件也逐漸增多。
隨著黑客團體的不斷成立和黑客技術(shù)的不斷普及，不僅越來越多的人成為攻擊者，
而且出于各種目的的攻擊行為絡繹不絕，部分黑客的惡意破壞攻擊行為嚴重影響
了社會的穩(wěn)定和發(fā)展，并且呈現(xiàn)出發(fā)生頻率和造成的破環(huán)程度有逐年激增的現(xiàn)象。
20世紀60年代，MIT等人工智能實驗室成為黑客初顯身手的舞臺。70年代，
一批當年北美大學生運動的領袖，西海岸反越戰(zhàn)活動的積極分子，爭民權(quán)的斗士
漸漸參加了黑客隊伍。黑客提倡了一場個人計算機革命，提出“計算機為人民所
用”的觀點。領頭人為蘋果公司創(chuàng)建人史蒂夫·喬布斯。黑客團體的出現(xiàn)也使得安
全事件越來越多。由于入侵事件層出不窮，迫使美國1986年通過“計算機欺詐與
濫用法案"。一年后，17歲的高中生赫爾波特·齊恩被指控闖入美國電話電報公司
內(nèi)部網(wǎng)絡和中心交換系統(tǒng)，成為“計算機欺詐與濫用法案"生效后被判有罪的第
一人。
隨著黑客團體的不斷成立和黑客技術(shù)的不斷普及，越來越多的人成為攻擊者，
包括大量中學生。如1979年，年僅15歲的凱文·米特尼克僅憑一臺電腦和一部調(diào)
制解調(diào)器闖入了北美空中防務指揮部的計算機主機。雖然部分黑客仍然帶有早期
黑客的騎士精神，但是更多的黑客可能會因為各種目的而發(fā)動攻擊。
有因為政治目的而發(fā)動的攻擊，如1989年，5名西德電腦間諜入侵美國政府
和大學電腦網(wǎng)絡，并最終因間諜罪被逮捕起訴；1991年海灣戰(zhàn)爭期間的荷蘭黑客
入侵國防部；2006年7月美國國務院電腦遭到攻擊。
有為謀求個人非法經(jīng)濟利益的黑客攻擊，如：2003年2月Visa公司遭到入侵，
220個Visa卡和萬事達卡被竊；2006年5月，廣西柳州市黑客利用盜竊的個人隱
私敲詐；2006年8月，黑客攻入AT&amp;amp;T公司計算機系統(tǒng)并接入了數(shù)千用戶存儲于
在線商店的個人數(shù)據(jù)，這只是AT&amp;amp;T遭到眾多入侵中的一次，2005年至2006年，
AT&amp;amp;T約有9000萬人的個人數(shù)據(jù)被入侵。
有發(fā)泄個人不滿發(fā)動的攻擊，如2006年6月對百度發(fā)動的“分布式拒絕服務
北京交通人學碩士學位論文
攻擊”，甚至還有僅僅為炫耀技術(shù)而發(fā)動的攻擊，如2005年4月黑客為招募仰慕
者對10個荊門市政府及1個醫(yī)院的網(wǎng)站發(fā)動攻擊。
黑客入侵和攻擊會造成巨大的損失，如1988年，一名23歲的黑客編制的病
毒感染了美國6000多臺計算機，造成直接經(jīng)濟損失9600萬美元；而據(jù)估計，僅
在2005年，全球由于黑客入侵和攻擊造成的損失超過1000億美元。大量發(fā)生的
入侵和攻擊事件在造成了巨大損失的同時，也阻礙了信息技術(shù)的進一步應用，國
內(nèi)電子商務的發(fā)展和應用進展緩慢就是一個例證。
于是越來越多的人開始關(guān)注信息安全，關(guān)注怎樣保證信息安全。下面我們要
對上述信息安全的威脅進行分析。
按照這些安全威脅的目的可以對它們?nèi)缦聞澐郑?
·竊取信息：數(shù)據(jù)被未經(jīng)授權(quán)的主體獲得；
·破壞完整性：數(shù)據(jù)被未經(jīng)授權(quán)主體創(chuàng)建、修改或刪除；
· 非法使用：數(shù)據(jù)被未經(jīng)授權(quán)主體使用；
·破壞可用性：提供給授權(quán)主體的數(shù)據(jù)或資源被蓄意阻止或延遲。
為了實現(xiàn)上述的攻擊目標，攻擊者可能采取多種手段來實施。常見攻擊手段
主要可以分為以下幾種：
·假冒：偽裝成另外一個不同的主體；
·越權(quán)：利用系統(tǒng)安全漏洞，超越所授權(quán)限而進行操作；
·木馬：在系統(tǒng)中植入能夠截獲數(shù)據(jù)或系統(tǒng)操作的代碼段；
· 后門：在系統(tǒng)中秘密開設能獲得較高權(quán)限的機關(guān)；
·拒絕服務攻擊：破壞系統(tǒng)的工作，阻礙其提供正常服務；
·破壞審計數(shù)據(jù)：破壞審計數(shù)據(jù)以逃避追蹤。
這里列出的信息安全威脅都是指應計算機系統(tǒng)中的信息安全威脅。按威脅目
的劃分中的竊取信息威脅是對計算機系統(tǒng)中的操作系統(tǒng)層的威脅，對主體的授權(quán)
是操作系統(tǒng)訪問控制機制提供的服務，同樣破壞完整性、非法使用和破壞可用性
都是操系統(tǒng)層的威脅，所以從信息安全威脅的角度分析，我們必須先從保證操作
系統(tǒng)安全來保證信息的安全。從攻擊手段的角度分析，主體的標識鑒別、審計是
操作系統(tǒng)提供的服務，系統(tǒng)安全漏洞是操作系統(tǒng)安全功能的不完善造成的，截獲
系統(tǒng)調(diào)用、在系統(tǒng)中設立后門也是操作系統(tǒng)層的威脅，所以保證操作的安全性同
樣是保證信息安全的首要任務。
從計算機系統(tǒng)結(jié)構(gòu)的角度分析，也必須先保證操作系統(tǒng)的安全。因為操作系
統(tǒng)是連接計算機硬件與上層軟件及用戶的橋梁，它的安全性是至關(guān)重要的。在信
息系統(tǒng)安全涉及的眾多內(nèi)容中，操作系統(tǒng)、網(wǎng)絡系統(tǒng)和數(shù)據(jù)庫管理系統(tǒng)的安全問
題是核心所在。運行狀態(tài)下的計算機系統(tǒng)層次結(jié)構(gòu)如圖1-1所示，從中不難看出，
2
緒論
操作系統(tǒng)承擔著整個軟件系統(tǒng)及用戶與硬件之間的橋梁紐帶作用。作為計算機軟
硬件資源的管理者，操作系統(tǒng)控制著整個計算機系統(tǒng)的運行，它直接和硬件打交
道并為用戶提供接口，是計算機軟件的運行基礎和核心。數(shù)據(jù)庫管理系統(tǒng)是建立
在操作系統(tǒng)之上的，如果沒有安全操作系統(tǒng)的支持，就不可能保障其訪問控制的
安全可信性。在網(wǎng)絡環(huán)境中，網(wǎng)絡安全依賴于各主機系統(tǒng)的安全可信性，沒有操
作系統(tǒng)的安全，就談不上主機系統(tǒng)和網(wǎng)絡系統(tǒng)的安全性。同樣，計算機應用軟件
都建立在操作系統(tǒng)之上，唯有通過安全操作系統(tǒng)才能實現(xiàn)它們對系統(tǒng)中有關(guān)信息
的安全存取與處理。因此，操作系統(tǒng)的安全是整個計算機系統(tǒng)安全的基礎，沒有
操作系統(tǒng)的安全，就不可能真正解決數(shù)據(jù)庫安全、網(wǎng)絡安全和其他應用軟件的安
全問題。
應用程序用戶
運行支持系統(tǒng)
操作系統(tǒng)
孝7 “一”i
i 計算機硬件即指令系統(tǒng)l
№；|_。一t 一，
。‘ @
圖1-1計算機系統(tǒng)運行時的層次結(jié)構(gòu)
Figure 1-1 Structure of the Running Computer System
由此，安全操作系統(tǒng)的研究引起了研究機構(gòu)的重視。20世紀60年代中期，美
國貝爾實驗室和麻省理工學院聯(lián)合開發(fā)了一個名為Multics的操作系統(tǒng)，這是被計
算機界認同的首個安全操作系統(tǒng)。以此為始，全球計算機界對安全操作系統(tǒng)的研
究和開發(fā)工作迅速開展起來。
1．1．2安全操作系統(tǒng)的發(fā)展
安全操作系統(tǒng)與操作系統(tǒng)安全的含義不盡相同，操作系統(tǒng)安全表達的是對操
作系統(tǒng)的安全需求，而安全操作系統(tǒng)是指其安全性有所保障的操作系統(tǒng)。但二者
又是統(tǒng)一的和密不可分的，因為它們所關(guān)注的都是操作系統(tǒng)的安全性。安全操作
系統(tǒng)通常與一定的安全等級相對應，例如，根據(jù)TCSEC標準，通常稱B1級以上的
操作系統(tǒng)為安全操作系統(tǒng)。
從20世紀60年代開始，安全操作系統(tǒng)引起了研究機構(gòu)的重視，至今，人們
己經(jīng)在這個領域付出了40余年的努力，開展了大量的工作，取得了豐富的成果，
安全操作系統(tǒng)理論和實現(xiàn)技術(shù)伴隨著操作系統(tǒng)和安全理論的發(fā)展而不斷完善。根
3
北京交通大學碩十學位論文
據(jù)研究與開發(fā)工作及其相應的技術(shù)成果的特點大致可被分為四個發(fā)展階段【8】：奠基
時期、食譜時期、多策略時期和動態(tài)策略時期，下面分別予以簡單介紹。
奠基時期：從1965年歷史上的第一個安全操作系統(tǒng)Multics誕生到20世紀
80年代術(shù)期，安全操作系統(tǒng)經(jīng)歷了從無到有的探索過程，安全操作系統(tǒng)的基本思
想和理論及研究方法逐步建立。其中由J．EAnderson提出的引用監(jiān)控機、引用驗證
機制、安全核和安全建模等重要思想，為安全操作系統(tǒng)的開發(fā)奠定了重要的基礎。
食譜時期：食譜時期始于1983年美國的TCSEC(Trusted Computer System
Evaluation Criteria，可信計算機系統(tǒng)評測標準)標準頒布之時。TCSEC，又稱橙皮
書，是歷史上第一個，也是著名的可信計算機系統(tǒng)評價標準，它為安全系統(tǒng)指定
的是一個單一的系統(tǒng)安全策略，諸如自主訪問控制和強制訪問控制等。這個時期
的安全操作系統(tǒng)開發(fā)幾乎都以TCSEC為范型，主要研究成果有AXIOM技術(shù)公司
的LINUS IV系統(tǒng)、美國貝爾實驗室的SystemV／MLS系統(tǒng)和加拿大多倫多大學的
安全TUNIS系統(tǒng)等。
多策略時期：隨著90年代初Internet的影響的迅速擴大，分布式應用的迅速
普及，單一安全策略的范型已不能滿足對安全策略需求多種多樣的現(xiàn)實應用。1993
年，美國國防部在TAFIM(Technical Architecture for Information Management)計
劃中推出新的安全體系結(jié)構(gòu)DGSA(DoD Goal SecurityArchitecture)來對多種安全
政策提供支持，這促使安全操作系統(tǒng)研究進入了一個新的時期——多策略時期。
動態(tài)策略時期：策略靈活性是動態(tài)策略時期的重要特征。這個時期安全操作
系統(tǒng)研發(fā)的特點是使安全操作系統(tǒng)支持多種安全策略的動態(tài)變化，從而實現(xiàn)安全
政策的多樣性和靈活性。1999年Flask安全體系結(jié)構(gòu)的誕生是動態(tài)策略時期的帷幕
徐徐打開的標志。目前比較流行的Linux安全操作系統(tǒng)SE．Linux就是由NAS
(National Security Agency，美國國家安全安全局)和NAI(網(wǎng)絡伙伴公司)實驗
室的基于Flask合作研制的。
相對來說，中國的安全操作系統(tǒng)研究起步比較晚。以Linux為代表的自由軟件
在中國的廣泛流行對中國安全操作系統(tǒng)的研究與開發(fā)具有積極的推動作用。Linux
操作系統(tǒng)性能優(yōu)良且源代碼開放。鑒于此，國內(nèi)諸多有識之士、學者及研究機構(gòu)
就安全操作系統(tǒng)的相關(guān)理論及基于Linux的安全操作系統(tǒng)的開發(fā)進行了深入的研
究，并在體系結(jié)構(gòu)、安全模型、系統(tǒng)構(gòu)建、安全測評等方面取得一定的成果。其
中比較突出的有中國科學院軟件所的9即斯?jié)h老師帶領的實驗室開發(fā)出的安全操作
系統(tǒng)——安勝，中國紅旗Linux公司推出的其自主研發(fā)的紅旗安全操作系統(tǒng)2．0。此
外，還有南京大學、中國計算機軟件與技術(shù)服務總公司等其它單位也以Linux為基
礎開展了安全操作系統(tǒng)的研究與開發(fā)工作。
4
緒論
1．1．3操作系統(tǒng)安全測評及其自動化
操作系統(tǒng)安全測評的意義：
操作系統(tǒng)安全性測評是實現(xiàn)安全操作系統(tǒng)的一個極為重要的環(huán)節(jié)，如果不測
評、驗證所開發(fā)操作系統(tǒng)的安全性和該安全性的可信度，那么開發(fā)出的該操作系
統(tǒng)的安全性就沒有保證，從而增加了它的應用風險。所以操作系統(tǒng)安全測評和操
作系統(tǒng)的設計開發(fā)一樣重要。操作系統(tǒng)安全測試是安全測評的基礎，操作系統(tǒng)安
全測評是建立在安全功能測試上對操作系統(tǒng)的安全性給出的評價。
美國國防部于1979年6月25日發(fā)布了世界上第一個計算機安全標準——軍
標DoD5200．28．M，標志著操作系統(tǒng)安全測評領域的開端。從這以后操作系統(tǒng)安全
的研究人員不僅致力于安全操作系統(tǒng)的開發(fā)，而且致力于操作系統(tǒng)安全的測評。
安全測評與安全測試的關(guān)系：
操作系統(tǒng)的安全測評是指對操作系統(tǒng)的安全性給出評估結(jié)果，測評是針對操
作系統(tǒng)這個整體來說的。安全測評應該由有測評資質(zhì)的第三方完成實施。安全測
試是針對操作系統(tǒng)的具體安全功能來說的，它一方面是安全操作系統(tǒng)測評的一個
極為重要的環(huán)節(jié)，即由開發(fā)方進行的安全功能測試，另一方面它是操作系統(tǒng)測評
的基礎，即由第三方測評人員進行的操作系統(tǒng)安全功能測試。
操作系統(tǒng)安全測評和安全測試的研究現(xiàn)狀：
操作系統(tǒng)安全測評方法的研究成果主要是由個別權(quán)威機構(gòu)提出的安全測評標
準中體現(xiàn)出的測評方法，對安全測評的研究體現(xiàn)在測評標準的制定、更新和完善
上。
國外對操作系統(tǒng)的安全測試的研究主要集中在對安全策略的分析、驗證、測
試【14】，安全策略的實施仍然依賴于操作系統(tǒng)基本的安全功能的基礎上，而國外對
操作系統(tǒng)安全功能測試的研究很少。
由于開源的Linux系統(tǒng)的推動，從上個世紀末開始國內(nèi)操作系統(tǒng)自主研發(fā)工作
蓬勃的展開。開發(fā)方為了使這些操作系統(tǒng)被采購和真正投入使用，就必須進行測
評，于是國內(nèi)也逐漸開始了對操作系統(tǒng)測評的研究，并且制定了安全測評的國家
標準。由于國內(nèi)和國外在安全測評領域還有一定的差距，國內(nèi)的安全標準都是參
照國際標準建立的。
國內(nèi)對操作系統(tǒng)安全測試的研究還處于起步階段，沒有理論化的測試方法，
大多是嘗試性的實踐。
操作系統(tǒng)安全測評自動化的研究現(xiàn)狀：
安全測評本身就是一個是一個非常大的課題，安全測評自動化系統(tǒng)則更加龐
大。國外對安全測評自動化的研究極少，有關(guān)測試自動化的研究大都是針對軟件
5
北京交通大學碩十學位論文
測試的。而且計算機安全是較為敏感的領域，公開的操作系統(tǒng)安全測試方法的資
料也較少。
操作系統(tǒng)安全測試多由生產(chǎn)商完成，整個測試過程是很昂貴的，而且基本均
依靠手工來完成，往往需幾年的時間。軟件測試中的自動化測試已經(jīng)有較長時間
的應用歷史，而在安全操作系統(tǒng)測評領域，手工測評仍然是最主要的測評方式。
所以對操作系統(tǒng)測試自動化是一項重要而且有意義的工作。
國內(nèi)一些學者對操作系統(tǒng)測評自動化給出一些設計方案，但離最終的實現(xiàn)還
有一定的距離。
1．2論文研究內(nèi)容
本文的研究內(nèi)容主要包括以下三個方面：
(1)概述了現(xiàn)有的安全測評標準，并對整個CC安全測評體系做了詳細的分
析，總結(jié)了CC安全體系測評方法的基本要領。
(2)分析了國內(nèi)兩種典型的安全測評自動化系統(tǒng)的設計方法，對其優(yōu)缺點做
了總結(jié)，通過吸取這些系統(tǒng)的優(yōu)點和融合了軟件測試自動化方法本文給出了改進
后的安全測評自動化框架設計，以及技術(shù)難點和解決方案。
(3)以Linux系統(tǒng)訪問控制安全為切入點，對操作系統(tǒng)安全測評自動化進行
了探索，并設計和實現(xiàn)了Linux訪問控制安全測試自動化工具。在人工編制用例轉(zhuǎn)
化規(guī)則的基礎上，該工具可以實現(xiàn)自動執(zhí)行XML語言描述的特定格式的訪問控制
安全測試用例，測試結(jié)果判斷和給出測試報告。
本論文工作及課題得到國家973項目“信息與網(wǎng)絡安全體系結(jié)構(gòu)研究”(項目
編號G1999035801)之子課題“操作系統(tǒng)安全評測平臺的研究’’及北京交通大學
?？萍蓟稹鞍踩僮飨到y(tǒng)測評自動化研究"(項目編號K06J0070)的支持。
1．3論文組織結(jié)構(gòu)
本論文分為五章，其結(jié)構(gòu)為：
第一章，緒論，介紹本課題的研究背景意義和研究現(xiàn)狀，本論文的研究內(nèi)容，
以及論文各部分的組織結(jié)構(gòu)。
第二章，操作系統(tǒng)安全測評的研究，本章概述了現(xiàn)有的安全測評標準，并著
重分析了CC安全測評體系，總結(jié)了CC安全體系測評方法的基本要領和測評流程。
第三章，操作系統(tǒng)安全測評自動化的研究，本章在總結(jié)已有的安全測評自動
化系統(tǒng)設計方法，對其優(yōu)缺點做了總結(jié)，在吸取其優(yōu)點和融合了軟件測試自動化
6
緒論
方法的基礎上，給出了改進的安全測評自動化框架設計，以及技術(shù)難點和解決方
案。
第四章，Linux訪問控制安全測試自動化工具的設計與實現(xiàn)，本章以Linux系
統(tǒng)訪問控制安全為切入點，對操作系統(tǒng)安全測評自動化進行了實踐，設計和實現(xiàn)
了Linux訪問控制安全測試自動化工具，并對其進行了討論。
第五章，結(jié)束語，包含了對論文的工作和研究成果進行總結(jié)和歸納，對Linux
安全測試自動化的下一步工作進行了展望。
7
操作系統(tǒng)安全測評的研究
2操作系統(tǒng)安全測評的研究
操作系統(tǒng)安全測評是較為前沿的研究領域，還沒有形成完整的理論體系，而
且只有了解了安全測評的方法和過程才有可能實現(xiàn)安全測評的自動化，因此應該
先對操作系統(tǒng)安全測評進行分析研究。
2．1 安全測評標準
安全測評標準是安全操作系統(tǒng)測評方法的體現(xiàn)，安全測評標準的發(fā)展歷程也
就是安全測評方法發(fā)展的過程。為了更好的探討和理解安全操作系統(tǒng)的測評方法，
我們有必要對安全測評標準發(fā)展過程中重要的測評標準做簡要的說明。
2．1．1 DoD5200．28．M
美國國防部1979年6月25日發(fā)布的軍標DoD5200．28．M為計算機安全系統(tǒng)
定義了四種不同的運行安全模式：受控的安全模式、自主安全模式、多級安全模
式、強制安全模式。DoD5200．28．M是世界上第一個計算機安全標準，對計算機系
統(tǒng)提出了一系列安全要求，旨在防止對系統(tǒng)意外或惡意侵害，并提供侵害日志記
錄。
2．1．2 TCSEC
1983年，美國國防部頒布了歷史上第一個計算機安全評價標準，這就是著名
的可信計算機系統(tǒng)評價標準，簡稱TCSECI剮，又稱橙皮書。1985年，美國國防部
對TCSEC進行了修訂。
如圖2．1所示，TCSEC定義了7個等級(D，C1，C2，B1，B2，B3，A1)
組成的4個類別，類A中的級別A1是最高安全級別，類D中的級別D1是最低安
全級別。類別用來度量提供安全保護的程度，每一個級別和類別都是在前一個基
礎上增加條款形成的。TCSEC還給出了與安全政策、責任、保障和文檔相關(guān)的27
條明確可操作的評估準則，并給出了TCSEC的測試需求。TCSEC準則的原理是：
在Cl級別設立基本安全要求，然后在高安全級別的每一層都加入新的需求。TCSEC
引入了“可信計算機基(TCB)"和“安全內(nèi)核(或引用監(jiān)視器)"兩個重要概念，
TCB是硬件、固件和實施某項安全政策的軟件的組合表示，是安全機制的抽象；
9
北京交通大學碩士學位論文
“安全內(nèi)核(或引用監(jiān)視器)”是硬件、固件和軟件的組合，該軟件不僅實現(xiàn)訪問
控制功能而且保護自己免受篡改，“安全內(nèi)核”實現(xiàn)了系統(tǒng)安全政策的強制訪問控
制功能，是安全機制的具體實現(xiàn)。TCSEC要求安全模型A1級別的設計必須通過
形式化的數(shù)學證明，形式化的安全模型在今天仍然具有其重要性，形式化可用于
安全系統(tǒng)的需求說明和設計驗證。
支全牛
D：最小保護
cl：白主安令保護
C2：受控訪問保護
Bl：標記安傘保護
B2：結(jié)構(gòu)化保護
B3：安傘域
Al：驗汗的沒汁
圖2-1 TCSEC的構(gòu)成與等級結(jié)構(gòu)
Figure 2-1 Structure of security levels for TCSEC
TCSEC的初衷主要針對集中式計算的分時多用戶操作系統(tǒng)，這套計算機安全
的規(guī)范與測試評估標準發(fā)布之后不久，人們就發(fā)現(xiàn)很難將橙皮書應用于網(wǎng)絡(分
布式)或數(shù)據(jù)庫管理系統(tǒng)(客戶服務器結(jié)構(gòu))。當分布式處理形成規(guī)范時，美國國
防部又頒布了對橙皮書的附加說明和解釋，提高了TCSEC標準的實用范圍。
2．1．3 GBl7859。1999
我國強制性國家標準——《計算機信息系統(tǒng)安全保護等級劃分準則》(GB
17859．1999)120】是在參考美國的TCSEC、可信計算機系統(tǒng)評估準則
(DoD5200．28．STD)和I n-J"信計算機網(wǎng)絡系統(tǒng)。既N(NCSC．TG．005)的基礎上，從自主訪
問控制、強制訪問控制、標記、身份鑒別、客體重用、審計、數(shù)據(jù)完整性、隱蔽
信道分析、可信路徑和可信恢復等10個方面來將計算機信息系統(tǒng)安全保護等級劃
分為五個安全等級。第一級：用戶自主保護級；第二級：系統(tǒng)審計保護級；第三
級：安全標記保護級；第四級：結(jié)構(gòu)化保護級；第五級：訪問驗證保護級。以下
簡要介紹五個安全級的基本特點。
用戶自主保護級的計算機信息系統(tǒng)可信計算基通過隔離用戶與數(shù)據(jù)，使用戶
具備自主安全保護的能力。安全機制包括自主訪問控制、身份鑒別、數(shù)據(jù)完整性。
與用戶自主保護級相比，系統(tǒng)審計保護級的計算機信息系統(tǒng)可信計算基實施
10
操作系統(tǒng)安全測評的研究
了粒度更細的自主訪問控制，它通過登錄規(guī)程、審計安全性相關(guān)事件和隔離資源，
使用戶對自己的行為負責。安全機制包括自主訪問控制、身份鑒別、客體重用、
審計、自主數(shù)據(jù)完整性策略。
安全標記保護級的計算機信息系統(tǒng)可信計算基具有系統(tǒng)審計保護級的所有功
能。此外，還需提供有關(guān)安全策略模型、數(shù)據(jù)標記以及主體對客體強制訪問控制
的非形式化描述，具有準確地標記輸出信息的能力，消除通過測試發(fā)現(xiàn)的任何錯
誤。安全機制包括自主訪問控制、強制訪問控制、標記、身份鑒別、客體重用、
審計、自主和強制數(shù)據(jù)完整性策略。
結(jié)構(gòu)化保護級的計算機信息系統(tǒng)可信計算基建立于一個明確定義的形式化安
全策略模型之上，它要求將第三級系統(tǒng)中的自主和強制訪問控制擴展到所有主體
與客體。此外，還要考慮隱蔽通道。本級的計算機信息系統(tǒng)可信計算基必須結(jié)構(gòu)
化為關(guān)鍵保護元素和非關(guān)鍵保護元素；計算機信息系統(tǒng)可信計算基的接口也必須
明確定義，使其設計與實現(xiàn)能經(jīng)受更充分的測試和更完整的復審；加強了鑒別機
制，支持系統(tǒng)管理員和操作員的職能，提供可信設施管理，增強了配置管理控制。
系統(tǒng)具有相當?shù)目節(jié)B透能力。安全機制包括自主訪問控制、強制訪問控制、標記、
身份鑒別、客體重用、審計、自主和強制數(shù)據(jù)完整性策略、隱蔽通道分析、可信
路徑。
訪問驗證保護級的計算機信息系統(tǒng)可信計算基滿足訪問監(jiān)控器需求。訪問監(jiān)
控器仲裁主體對客體的全部訪問。訪問監(jiān)控器本身是抗篡改的，必須足夠小，能
夠分析和測試。為了滿足訪問監(jiān)控器需求，計算機信息系統(tǒng)可信計算基在其構(gòu)造
時，排除那些對實施安全策略來說并非必要的代碼，在設計和現(xiàn)實時，從系統(tǒng)工
程角度將其復雜性降低到最小程度；支持安全管理員職能，擴充審計機制，當發(fā)
生與安全相關(guān)的事件時發(fā)出信號；提供系統(tǒng)恢復機制；系統(tǒng)具有很高的抗?jié)B透能
力。安全機制包括自主訪問控制、強制訪問控制、標記、身份鑒別、客體重用、
審計、自主和強制數(shù)據(jù)完整性策略、隱蔽通道分析、可信路徑、可信恢復。
2．1．4 ITSEC、CTCPEC及FC
TCSEC測評標準應用于非操作系統(tǒng)類以及測評標準的分級比較困難。因為它
要求安全產(chǎn)品為了達到某個評估級別，底層操作系統(tǒng)必須完全滿足相應的功能要
求。新范式的思想就是將通信保密和計算機安全合為一體，通稱為信息安全，用
于保護信息免受偶然或惡意的非法泄密、轉(zhuǎn)移或破壞，這就是80年代末出現(xiàn)的
ITSEC。ITSEC將安全性要求分為“功能’’和“保證’’兩部分。其中，“功能”指
為滿足安全需求而采取的一系列技術(shù)安全措施，如訪問控制、審計、鑒別、數(shù)字
北京交通人學碩士學位論文
簽名等；“保證"指確?！肮δ堋闭_實現(xiàn)及其有效性的安全措施。
ITSEC根據(jù)保證要求定義了七個評估級別：E0到E6。其中E1到E5為：
●E1：測試：
·E2：配置控制和可控交付；
·E3-能訪問詳細設計和源碼；
◆E4：詳細的脆弱性分析；
●E4：設計與源碼明顯對應；
●E5：設計與源碼在形式上一致；
功能要求在測定上分F1到F10共10級。1至5級對應于TCSEC的D到A，
6．10級加上了以下概念：
·F6：數(shù)據(jù)和程序的完整性；
·F7：系統(tǒng)可用性；
●F8：數(shù)據(jù)通信完整性；
●F9：數(shù)據(jù)通信保密性；
·F10；包括機密性和完整性的網(wǎng)絡安全。
加拿大可信計算機產(chǎn)品評估準則CTCPEC verl．0于1989年公布，專為政府需
求而設計。CTCPEC將安全分為功能性要求和保證性要求兩部分。功能性要求分
為機密性、完整性、可用性、可控性等四個大類。在每種安全要求下又分成多級，
用于表示安全性上的差別，并按程度不同分為0．5級。
FC基于MSFR和加拿大的CTCPEC，其中MSFR是FC針對TCSEC的C2
級要求提出了適用于商業(yè)組織和政府部門的最小安全功能要求。在此標準中首先
引入了“保護輪廓(PP)”這一重要概念，每個保護輪廓都包括功能部分、開發(fā)保
證部分和評測部分，規(guī)定了信息產(chǎn)品或系統(tǒng)的技術(shù)要求。主要供美國政府使用、
民用和商用。
2．1．5 CC(GB／T18336—2001)
進入90年代中期，信息技術(shù)安全評估通用標準CCtll產(chǎn)生，CC是加拿大、法
國、德國、荷蘭、英國和美國六個國家共同努力的成果。CC標準是現(xiàn)階段最完善
的信息技術(shù)安全性評估準則。
CC標準將信息技術(shù)安全要求分為“功能”和“保證"兩大部分?！肮δ芤?quot;
是希望對產(chǎn)品提供的安全功能或特征的描述，“保證要求”能夠讓用戶相信功能要
求能夠得到滿足，這與許多國際標準中的區(qū)分相類似。CC定義了安全功能要求的
類、族和組件結(jié)構(gòu)劃分，提出了常見的安全功能要求的11個功能類的135個功能
12
操作系統(tǒng)安全測評的研究
組件，給CC標準的使用者提供直接的參考。用戶可以從該結(jié)構(gòu)中選擇合適的組件
來定義他們對產(chǎn)品的安全功能要求，編制PP；開發(fā)人員可以選擇適當組件定義產(chǎn)
品的安全功能，編制ST；測評人員同樣可以選擇適當?shù)慕M件定義測評內(nèi)容，編制
包。CC的這種結(jié)構(gòu)形式使得制定標準是具有很好的結(jié)構(gòu)性和可操作性。標準起草
人僅對部分組件提出了詳細的具體的規(guī)范，對不能詳盡規(guī)范的組件只提出了初步
的規(guī)定，將組件的具體規(guī)范留給了標準使用者。CC也定義了安全保證要求的類、
族和部件的結(jié)構(gòu)劃分，用于保障rr產(chǎn)品或系統(tǒng)滿足它的安全目標，安全保證需求
使用評估保證級別(EAL)進行區(qū)別。
與早期的評估準則相比，CC的特點體現(xiàn)在其結(jié)構(gòu)的開放性、表達方式的通用
性以及結(jié)構(gòu)和表達方式的內(nèi)在完備性和實用性四個方面。
CC的最基本思想是：基于可信的rr產(chǎn)品或系統(tǒng)評估，為用戶使用產(chǎn)品或系
統(tǒng)提供信心保證。下一節(jié)我們將對CC安全測評體系進行詳細分析。
國標GB／"r18336．2001是在翻譯了CC標準的基礎上建立的，這個就不再分析。
2．2 CC安全測評體系分析
在IT安全產(chǎn)品測評方面，包括操作系統(tǒng)測評，我們國家和發(fā)達國家還有一定
的差距，為了縮小這種差距，同時總結(jié)安全測評的方法和流程，我們對整個CC體
系結(jié)構(gòu)做了分析。CC是一個龐大的安全測評體系，僅文檔就有1111頁。在本文
完成之時，國內(nèi)有很多操作系統(tǒng)測評的實施是依據(jù)在CC標準的，但部分文獻對
CC的理解是不全面、不完整的，因此非常有必要對CC標準的使用方法以及用CC
標準進行操作系統(tǒng)安全測評的方法、流程和步驟進行分析和總結(jié)。
CC標準的全稱是Common Criteria for Information Technology Security
Evaluation，即信息技術(shù)安全性評價通用準則。對CC傳統(tǒng)的理解是指這篇信息技
術(shù)安全性通用準則本身。實際上完整的Common Criteria體系一共包括三大部分，
第一部分是Common Criteria for Information Technology Security Evaluation(CC)
信息技術(shù)安全性評價通用準則，第二部分是Common Methodology for Information
Technology Security Evaluation(CEM)信息技術(shù)安全評價通用方法，第三部分是
Common Criteria Recognition Agreement(CCRA)通用準則識別協(xié)議。整個CC體系
可以通過其官方網(wǎng)站http：／／www．commoncriteriaportal．org獲取。CC還在不斷完善
的過程中，不同版本之問有差異，下面我們分析所用的CC版本是2006年9月的
Version 3．1，CEM的版本是2007年9月的Version 3．1 Revision 2，CCRA的版本是
2000年5月版。
北京交通大學碩士學位論文
2．2．1信息技術(shù)安全評估通用標準(CC)
2．2．1．1 CC概要
CC[1J為IT產(chǎn)品提供了的一系列通用的安全功能需求和安全保證需求，它可以
用作安全功能的IT產(chǎn)品作為開發(fā)、評價和采購的指導。
CC分為三個部分，每個部分的內(nèi)容如下：
·第1部分：簡介和一般模型。該部分是CC的總體結(jié)構(gòu)簡介，定義了信息
技術(shù)安全性評估的一般概念和原理，并提出了評估的一般模型，整個評估
的過程都要遵循這個一般模型。
·第2部分：安全功能組件。該部分建立了一系列功能組件作為TOE基本
功能需求的標準模板。
·第3部分：安全保證組件。該部分建立了一系列保證組件作為TOE的基
本保證需求的標準模板。該部分包括了PP和ST的評價準則等安全保證
需求，而且介紹了7個被稱為評價保證級別的保證包。
CC中的重要概念：
CC標準涉及以下幾個關(guān)鍵概念，這幾個概念一致貫穿整個CC標準。其中的
保護輪廓、安全目標、組件和包都是CC結(jié)構(gòu)的重要組成部分。
評估對象(TOE)：作為安全性評估對象的一系列軟件、固件或硬件以及它們
的文檔，如操作系統(tǒng)、防火墻產(chǎn)品、計算機網(wǎng)絡、密碼模塊等，以及相關(guān)的管理
員指南、用戶指南、設計方案等文檔。
保護輪廓(PP)：PP是一種TOE類型的安全需求的獨立的強制性描述。PP是
用戶對安全需求的明確表述。一個PP為一類TOE基于其應用環(huán)境定義了一組安
全要求，而不管這些要求具體如何實現(xiàn)，實現(xiàn)問題由“安全目標”來解決。換句
話說，PP與某一個具體的TOE無關(guān)，它定義的是用戶對這類TOE的安全需求，
規(guī)定了一類TOE的安全性技術(shù)要求以及確保正確有效地實現(xiàn)這些要求的安全保證
措施。主要內(nèi)容包括：
·需要保護的對象，對該類產(chǎn)品或系統(tǒng)的界定性描述；
·確定安全環(huán)境，指名安全問題，如需要保護的資產(chǎn)、己知的威脅、用戶的
組織、安全策略等；
·TOE的安全目的，對安全問題的相應對策，包括技術(shù)性和非技術(shù)性措旄；
· 信息技術(shù)安全需求，包括功能需求、保證需求和環(huán)境安全需求，這些需求
通過滿足安全目的，進一步提出具體在技術(shù)上如何解決安全問題；
◆基本原理，指明安全需求對安全目的、安全目的對安全環(huán)境是充分且必要
14
操作系統(tǒng)安全測評的研究
的；
· 附加的補充說明信息。在標準體系中PP相當于產(chǎn)品標準，它有助于過程
規(guī)范性標準的開發(fā)。國內(nèi)外現(xiàn)已對應用級防火墻、包過濾防火墻、智能卡、
數(shù)據(jù)庫、訪問控制、入侵檢測、PKI、VPN、網(wǎng)上證券委托等產(chǎn)品或系統(tǒng)
開發(fā)了相應的PP。
TOE安全目標(ST)：ST的開發(fā)是針對具體的TOE而言的，它包括該TOE的
安全目的和能滿足安全目的安全需求，以及為滿足安全要求而提供的特定安全性
技術(shù)要求和保證措施。其中的技術(shù)要求和保證措施可以直接引用該TOE所屬產(chǎn)品
或系統(tǒng)類的PP，可以直接引用CC中的安全功能或保證組件，也可以針對具體實
際而明確陳述。由于ST是對特定TOE而開發(fā)的，通過安全性評估可以證明該TOE
所要實現(xiàn)的技術(shù)和保證措施，對滿足指定安全需求和目的而言是有用和有效的。
因此ST是開發(fā)者、評估者、用戶在TOE安全性和評估范圍之間達成一致的基礎。
ST相當于產(chǎn)品或系統(tǒng)的實現(xiàn)方案。由于ST與具體的TOE實現(xiàn)有關(guān)，因此可以滿
足一個或多個PP提出的要求，如某一防火墻的ST可能同時滿足包過濾防火墻PP
和應用級防火墻PP的要求。
組件(Component)：組件是CC的一個關(guān)鍵概念，描述一組特定的安全需求，
是可供PP、ST或包選取的最小安全需求集合，即將傳統(tǒng)的安全需求分成不能再分
的塊。
包(Package)：組件依據(jù)某一特定關(guān)系的組合在一起就構(gòu)成包。構(gòu)建包的目的
是定義那些公認有用的、對滿足某一特定安全目的有效的安全要求。包可用于構(gòu)
造更大的包、PP和ST或測評使用。例如測評人員可以根據(jù)將CC中某個安全等級
指定的組件放在一起組成一個典型的包——評估保證包。
CC各部分的作用：
通常CC只被認為是一個IT安全產(chǎn)品的評價準則，但是CC的作用不僅在于
對測評對象的評價，對于rr產(chǎn)品的消費者和開發(fā)者都有非常重要的作用。從另一
個角度來說，CC關(guān)注的不僅是測評，而是整個IT安全產(chǎn)品的生命周期。CC的三
個部分對其三組主要目標讀者而言，作用如表2-1所示。用戶在IT安全產(chǎn)品開發(fā)
之前應該在專業(yè)人事的幫助下按照CC安全功能組件提出對產(chǎn)品的安全需求，即保
護輪廓(PP)；在產(chǎn)品設計階段開發(fā)人員應該按照CC安全功能組件形成對IT安全
安全功能的設計的描述(ST)；在產(chǎn)品完成之后，認證機構(gòu)應該根據(jù)CC安全保證
組件對PP、ST等進行安全保證的測評和對TOE進行安全功能的測評。
北京交通大學碩十學位論文
表2-1 CC各部分的作用
Table 2-1 Road Map to the Common Criteria
用戶開發(fā)者評估者
第1 用于了解背景信息和參用于了解背景信息，開用于了解背景信息和參考，即安
部分考，即安全功能需求發(fā)安全要求和形成TOE 全功能需求(PP)和TOE安全
(PP)的指導性結(jié)構(gòu)安全規(guī)范(ST)的參考規(guī)范(ST)的指導性結(jié)構(gòu)
第2 在闡明安全功能需求用于解釋功能要求和生當確定TOE是否有效地符合已
部分(PP)的描述時用作指成TOE功能規(guī)范(ST) 聲明的安全功能時，用作評估準
導和參考的參考則的強制性描述
第3 用于指導保證要求級別當解釋保證要求描述和當確定TOE的保證和評估安全
部分的確定確定TOE的保證措施功能需求(PP)和安全規(guī)范(ST)
時，用作參考時，用作評估準則的強制描述
2．2．1．2安全功能組件
CC通過“類(Class)一族(Family)一組件(Component)”結(jié)構(gòu)組織安全功
能需求。每一個類代表一類安全功能，其中包括類名，類介紹和一個或多個功能
族。如圖2．2所示。每一個功能類有一個唯一的類名；類介紹表達了為了滿足安全
目的族的共同意圖和方法。
圖2—2 CC安全功能類的組織結(jié)構(gòu)
Figure 2-2 Orgnization of security functional classes for CC
每個族是更加具體的安全功能分支，內(nèi)容包括族名、族行為、組件級別、管
理、審計和組件，如圖2．3所示。族名也是唯一的標識，是用來提供分類信息的，
形式為“XXX—YYY"；族行為是關(guān)于功能族的安全目的和功能需求一般性說明
的敘述性描述，其中族的安全目的描述了在TOE的幫助下可能被解決的安全問題，
16
操作系統(tǒng)安全測評的研究
族的功能需求總結(jié)了所有組件的需求，目的是為了讓PP、ST和包的作者用例判定
這個族和他們的特定需求是否相關(guān)；功能族包括一個或多個組件，每一個都有可
能被包含在PP、ST或包中，組件級別通過描述組件的基本原理為用戶提供了選擇
一個合理的功能組件時所需的信息，一個族中的組件之間有可能有或沒有等級關(guān)
系，如果一個組件提供更多的安全那么該組件的等級比其他組件高；管理中包含
PP／ST作者用作管理行為的信息，涉及到了FMT類中的組件，提供了關(guān)于潛在管
理行為的指南，這些管理行為通過操作應用于組件，PP／ST作者可以選擇需要的管
理組件或可以包含其他沒有列出的管理需求來詳述管理行為；如果安全審計類被
包含在PP／ST中，審計才起作用，審計分為最小、一般、詳細三個級別描述了每
個族中需要審計的內(nèi)容。
圖2-3 CC安全功能族的組織結(jié)構(gòu)
Figure 2-3 Orgnization of security functional families for CC
組件的結(jié)構(gòu)如圖2．4所示。組件標識描述了鑒別、分類、注冊和參照組件時所
需的信息，每一個組件都有一個唯一的標識，標識包含一個唯一的標識名、一個
標識名縮寫和等級列表；功能組件之間可能存在依賴性，組件可能依賴于其他組
件的功能性或和其他組件的功能性有交互作用，依賴性提供了組件之間的依賴關(guān)
系信息，編制PP、ST或包時必須遵守這些依賴關(guān)系；組件中包含一個或功能元素，
每一個元素被獨立定義，功能元素是安全功能需求的最小單元，在編制PP、ST或
包時，不能從組件只選擇中一個或多個元素，應該將一個組件中的所有元素包含
在PP、ST或包時中。
17
北京交通大學碩士學位論文
圖2-4 CC安全功能類的組織結(jié)構(gòu)
Figure 2-4 Orgnization of security functional components for CC
安全功能需求一共包括11個類、66個族和135個組件。這11個類分別是：
FAU，安全審計類；FCO，通信類；FCS，密碼支持類；FDP，用戶數(shù)據(jù)保護類；
FIA，標識與鑒別類；FMT，安全管理類；FPR，用戶身份私有類；FPT，TSF保
護類；FRU，資源利用類；FFA，TOE訪問類；FTP，可信路徑／通道類。
2．2．1．3安全保證組件
安全保證類的組織結(jié)構(gòu)和安全功能需求的組織結(jié)構(gòu)類似，如圖2．5所示。保證
類的類名、類介紹、族名、組件標識、組件依賴關(guān)系和組件中的元素和功能類的
類似，族目的和組件目的分別介紹了保證族、組件的意圖；應用提示是包含描述
引起使用者注意的應用信息。
安全保證需求一共包括8個類，38個族。這8個類分別是：APE，保護輪廓
(PP)評估類；ASE，安全目標(ST)評估類；ADV，開發(fā)類；AGD，指導文檔
類；ALC，生命周期類；ATE，測試類；AVA，脆弱性評估類；ACO，組合類。
安全保證中還包含對7個劇兒(Evaluation Assurance Levels)級別的定義：
·EALl：功能型測試級，證明TOE與功能規(guī)格的一致
·EAL2：結(jié)構(gòu)性測試級，證明TOE與系統(tǒng)層次設計概念一致
·EAL3：工程方法上的測試及驗證級，證明TOE在設計上采用了積極安全
的工程方法。
●EAL4：工程方法上的方法設計、測試和評審級，證明TOE采用了基于良
好開發(fā)過程的安全工程方法。
●EAL5：半形式化設計和測試級，證明TOE采用了基于嚴格的過程的安全
工程方法并適度應用了專家安全工程技術(shù)。
·EAL6：半形式化地驗證設計和測試級，證明TOE將安全工程技術(shù)應用到
嚴格地開發(fā)環(huán)境中來達到消除大風險保護高價值資產(chǎn)。
18
操作系統(tǒng)安全測評的研究
·EAL7：形式化地驗證設計和測試級，證明TOE所有安全功能經(jīng)得起全面
的形式化分析。
圖2．5 CC中安全保證的組織結(jié)構(gòu)
Figure 2-5 Orgnization of security assurance of CC
安全級別和組件之間的關(guān)系可以用一張表概括，如表2．2所示。每一個安全級
別和每個族中的一個或零個組件對應，測評時可以根據(jù)需要達到的安全級別選擇
相應的安全保證組件。表格中的數(shù)字為組件的編號。
表2．2安全級別與組件之間的關(guān)系
Table 2-2 Relation between evaluation assurance level and components
保證組件
保證類保證族
EALl EAL2 EAI 3 EAI 4 EAL5 EAI．6 EAl7
爹甓÷霧嘲
ADV ARC 鏊女娩毖l渤1 1 1 1 1 1
ADV——FSP 1 2 3 4 5 5 6
ADV IMP ∥滯獬緩彩彬燃鋤舅
開發(fā)
夠一1 1 2 2
ADV——INT 爹∥節(jié)掰笏泐餮
2 3 3
免即。2。搿纓
ADV SPM 罄。．螽荔荔窿。霪黲． 《§藏磊魏赫，磊荔i 瓣勃荔騶磊瓏凝溉施彩貔彩黝1 1
笏． 自
ADV——TDS 貔滋滋㈧1 2 3 4 5 6
19
北京交通入學碩士學位論文
2．2．1．4 CC測評流程
圖2．6CC測評流程
Figure 2-6 Proess of the CC elvaluation
對CC測評流程的總結(jié)如圖2-6所示，由上圖可以看出CC測評標準不僅關(guān)注
與信息安全產(chǎn)品的安全功能，而且關(guān)注產(chǎn)品的整個生命周期，即從用戶安全需求
PP的評估，到開發(fā)發(fā)對安全目標的設計ST的評估，再到產(chǎn)品手冊的評估、產(chǎn)品
開發(fā)過程的評估、產(chǎn)品脆弱性和組合安全評估，最后還有對安全功能測試的評估
等。由此可見，CC對安全產(chǎn)品的評估是非常全面的。
2．2．2信息技術(shù)安全評估通用方法(CEM)
CEM[21是為了進行CC評估而開發(fā)的一種國際公認方法。CEM支撐信息安全
評估的國際互認。CEM主要是針對評估者而開發(fā)的。其他團體如開發(fā)者、發(fā)起者、
監(jiān)督者和其他與發(fā)布、使用評估結(jié)果有關(guān)的團體也都可以從CEM中得到一些有用
的信息。
操作系統(tǒng)安全測評的研究
評估過程由對開發(fā)過程和測試過程所執(zhí)行的評估行為組成，其中開發(fā)過程和
檢測過程必須遵循評估方法。也有部分行為，雖然在開發(fā)過程和檢測過程中，但
不在評估過程和CEM之中。
CEM的組織結(jié)構(gòu)和CC類似，先介紹了CEM的結(jié)構(gòu)和評估模型，之后對CC
安全保證的每個組件都給出了評估模型中的四個任務，即對開發(fā)過程和測試過程
評估方法的解釋，最后介紹了作為證明評估結(jié)果依據(jù)的基本評估技術(shù)，和對脆弱
性分析標準的解釋和應用實例。
2．2．2．1評估方法的組織結(jié)構(gòu)
如同CC用類、組件來對安全功能或安全保證進行組織，CEM以活動、子活
動和行為來組織對評估方法的說明。CC中的類、組件、評估人員行為元素分別和
CEM中的活動、子活動和行為對應，CC中的每個保證類在CEM中都有一個活動
與之對應，每個組件都有子活動相對應，子活動由多個行為，行為詳細說明的相
關(guān)保證組件的評估方法?；顒?、子活動的分類標識符和CC中的保證類的類、組件
標識符一致。
2．2．2．2一般模型
為了消除不正當?shù)膲毫υu估的影響，CEM定義了四個角色：發(fā)起者，開發(fā)
者，評估者和評估權(quán)威機構(gòu)。發(fā)起者負責請求和支持評估，負責建立評估協(xié)議(即
委任評估)，并且保證評估著提供評估證據(jù)。開發(fā)者開發(fā)TOE并且對于提供的評估
所需的證據(jù)負責(即培訓，設計信息)。評估者執(zhí)行評估任務，評估者代表發(fā)起者
從開發(fā)者處或直接從發(fā)起者處接收評估證據(jù)，執(zhí)行評估子活動并且提供評估結(jié)果
給評估權(quán)威。評估權(quán)威機構(gòu)建立并且維護計劃，評估者的評估進行監(jiān)督，并且根
據(jù)評估結(jié)果發(fā)布檢驗報告證明給評估者。
CEM定義了評估模型，用這個評估模型來介紹每個族的評估方法。評估模型
通常有四個任務：輸入任務，輸出任務，評估子活動，及評估人員的評估技術(shù)能
力范例。輸入列出了評估人員評估時需要使用的材料；輸出包括觀察報告(0R)
和評估技術(shù)報告(ETR)；評估子活動包含多個行為，即對評估方法的說明。
2．2．2．3觀察報告和評估報告
輸出分為觀察報告(0R)和評估技術(shù)報告(ETR)。其中OR為評估人員提供
21
北京交通大學碩士學位論文
了一種機制從評估的角度來澄清和確定問題。如果判定失敗，評估人員可以利用
OR來說明評估結(jié)果。
OR的內(nèi)容包括一下方面：PP或TOE標識符、得出觀察結(jié)果的評估任務／子活
動、觀察結(jié)果、對嚴重性的評估(例如，指出一個失敗的判定、阻止了評估的繼
續(xù)進行、需要在評估完成之前做裁決)、鑒定負責解決這個問題的組織、推薦的解
決時間表、沒有解決對評估影響的估價。
CEM給出的評估技術(shù)報告(ETR)的結(jié)構(gòu)分為8個部分，分別是介紹、TOE
結(jié)構(gòu)描述、評估方法技術(shù)和工具、評估結(jié)果、結(jié)論和建議、評估證據(jù)列表、術(shù)語
表和觀察報告。PP的ETR中沒有TOE結(jié)構(gòu)描述這一項。
2．2．2．4評估結(jié)果判定定義
CEM還給出了評估判定的定義。判定分為四個層次，評估行為單元判定，安
全保證組件判定，安全保證類判定，評估結(jié)果判定。每個層次的判定都是在其上
一個層次基礎上做出的，如果上一層有一個以上的失敗判定，那這一次的判定也
為失敗。CEM認可三種互斥的判定類型是通過、失敗和未決定，CEM對這三中判
定給出的明確的定義。
2．2．3通用準則識別協(xié)議(CCRA)
CCRA[3l中列出了有CC認證授權(quán)的參與者(Participants)，例如美國國家安全
局、加拿大國家通信安全機構(gòu)、芬蘭國家財政部、希臘內(nèi)政部等，之后詳細敘述
了這些機構(gòu)的權(quán)利、職能、管理等方面的要求和規(guī)定。
參與者可以授權(quán)有資質(zhì)的認證機構(gòu)(CBs)進行CC認證的權(quán)利，并列出了對這
些機構(gòu)的要求。例如，美國國家信息保證伙伴一通用準則評價和確認計劃、加拿
大通用準則評價和認證計劃等都是CBs。
經(jīng)過認證授權(quán)的IT產(chǎn)品有權(quán)利在產(chǎn)品上使用如圖2．7所示的標志。這個標志表
明參與者已經(jīng)授權(quán)CC認證。
圖2．7CC認證標志
Figure 2-7 Mark of the Product which has been authorised
操作系統(tǒng)安全測評的研究
圖2．8CC授權(quán)機構(gòu)標志
Figure 2-8 Mark of the Participant Or CBs
致力于支持該體系的原則，服從和同意現(xiàn)有的參與者的國家代表都可以被吸
納為新的CC參與者。遺憾的是中國還沒有成為CC的參與者。
2．3 操作系統(tǒng)安全測評方法
通常操作系統(tǒng)安全測評方法有形式化驗證、非形式化確認、入侵檢測和隱蔽
通道分析幾種。這些方法是獨立的，可以根據(jù)不同的開發(fā)階段及相應測評對象形
式的不同，采用不同的方法，對操作系統(tǒng)的測評需要把它們綜合起來。
形式化驗證：
形式化驗證是分析操作系統(tǒng)最精確的方法。在形式化驗證中，安全操作系統(tǒng)
被簡化為一個要證明的“定理"。定理斷言該安全操作系統(tǒng)是正確的，即它提供了
所有所應提供的安全特性，而不提供任何其它功能。但是，證明整個操作系統(tǒng)的
正確性的工作量是巨大的，形式化驗證也是一個復雜的過程。特別是對于大型的
系統(tǒng)，形勢化驗證是非常復雜的。
形式化驗證方法主要應用于對安全機制或安全策略模型的分析驗證中。通過
形式化的驗證，測評人員可以判斷安全機制或安全策略模型是否完好的定義了操
作系統(tǒng)的安全目標。
非形式化確認：
“確認”的概念更為廣泛、普遍，它包括驗證，同時也包括其他一些不太嚴
格的讓人們相信程序正確性的方法。要完成一個安全操作系統(tǒng)確認，可以結(jié)合安
全需求檢查、設計及代碼檢查、功能規(guī)范檢查和模塊及系統(tǒng)測試等方法。
關(guān)于安全需求檢查，應根據(jù)TCSEC、CC等測評標準并綜合考慮相關(guān)因素，
就Linux操作系統(tǒng)的安全需求展開廣泛深入的討論，逐條分析是否在需求說明書中
準確完整地體現(xiàn)；關(guān)于功能規(guī)范確認，應在Linux安全操作系統(tǒng)的需求說明書的基
礎上，檢查有關(guān)需求是否準確和充分體現(xiàn)到特定的功能或功能組合上；以此類推，
后一階段的安全評審與確認應在前一階段的評審成果的基礎上展開，確保彼此問
的一致性。至于代碼設計與系統(tǒng)實現(xiàn)階段的評審，還應檢查代碼自身的安全性。
在完成和實現(xiàn)系統(tǒng)代碼之后，通?？刹捎孟到y(tǒng)測試的方法進行安全測評。對于每
北京交通大學碩十學位論文
一個相對獨立的模塊而言，可以使用白盒測試的方法設計測試用例和展開對應模
塊的運行和測試；對于若干相關(guān)模塊而言，可基于白盒測試與黑盒測試相結(jié)合的
方法設計測試用例和展開集成測試；對于確認測試階段功能規(guī)范與安全需求的驗
證，則主要基于黑盒測試及功能需求表設計測試用例，并通過源代碼或系統(tǒng)運行
時所表現(xiàn)的安全功能交叉檢查操作系統(tǒng)的每個安全需求。
入侵檢測：
模擬入侵檢測可作為安全操作系統(tǒng)安全測評的輔助手段。其基本出發(fā)點是設
立由熟悉操作系統(tǒng)典型安全漏洞的成員所構(gòu)成的所謂“老虎小組”，讓他們利用安
全漏洞掃描軟件等嘗試發(fā)現(xiàn)可能存在的系統(tǒng)配置等安全漏洞，并進一步通過植入
黑客窺視文件或特洛伊木馬竊取口令帳號、完成關(guān)鍵系統(tǒng)文件非授權(quán)修改甚至摧
毀正在測試中的安全操作系統(tǒng)。這種方法就是試圖摧毀正在測試中的安全操作系
統(tǒng)。如果操作系統(tǒng)在某一次入侵測試中失效，則說明它內(nèi)部有錯誤。
隱蔽通道分析：
研究高安全性的可信計算機系統(tǒng)必須進行隱蔽通道分析，盡可能地搜索出所
有的隱蔽通道，測量或估計它們的帶寬并給予適當?shù)奶幚?，以控制隱蔽通道對系
統(tǒng)的破壞。因此，隱蔽通道的分析一般包含3個方面的內(nèi)容：(1)隱蔽通道標識；
(2)隱蔽通道帶寬的計算與工程測量；(3)對被標識的隱蔽通道進行適當?shù)奶?
理。
2．4 小結(jié)
本章分析了現(xiàn)有的安全測評標準內(nèi)容特點和應用范圍。由于CC標準是現(xiàn)階段
最為完善的測評標準，所以我們整個CC安全測評體體系進行了詳細的分析，并給
出了操作系統(tǒng)安全測評方法的總結(jié)。
操作系統(tǒng)安全測評自動化的研究
3操作系統(tǒng)安全測評自動化的研究
本章的主要任務是對操作系統(tǒng)測評自動化方法的研究?，F(xiàn)有的自動化方法和
技術(shù)基本是針對軟件測試的，本章在總結(jié)了軟件測試自動化的方法和技術(shù)并分析
了國內(nèi)現(xiàn)有的兩種操作系統(tǒng)測評自動化系統(tǒng)的基礎上，將軟件測試自動化方法融
入到操作系統(tǒng)安全測評中，給出了改進后的操作系統(tǒng)安全測評自動化框架。
3．1 軟件測試自動化
操作系統(tǒng)的測試和軟件測試的過程類似。也需要經(jīng)歷如圖3-1所示的測試過
程。圖3-1是軟件測試V模型圖，V模型中的過程從左到右，描述了基本的開發(fā)
過程和測試行為。
圖3—1軟件測試V模型
Figure 3-1 V model of sof細are development and testing
操作系統(tǒng)的安全測試相當于軟件測試中的系統(tǒng)測試。通過安全測試，可以驗
證和確保安全操作系統(tǒng)的安全功能實現(xiàn)。所以軟件測試自動化的方法和技術(shù)可以
應用于安全測評自動化領域。
軟件測試自動化是指使用軟件來控制測試的執(zhí)行、實際輸出和預期輸出的對
比、測試前提條件的構(gòu)建、測試過程的執(zhí)行以及其他測試控制條件和測試報告的
輸出。實際上自動化測試和手工測試之間往往并沒有明確的界限。很多測試往往
并不能完全通過自動化測試完成，自動化到不需要人工參與的程度是不現(xiàn)實的。
軟件測試自動化，是一項讓計算機代替測試人員進行軟件測試的技術(shù)。它可
以讓測試人員從繁瑣和重復的測試活動中解脫出來，專心從事有意義的測試設計
北京交通大學碩士學位論文
等活動。如果采用自動比較技術(shù)，還可以自動完成測試用例執(zhí)行結(jié)果的判斷，從
而避免人工比對存在的疏漏問題。
軟件測試自動化通常借助測試工具進行。測試工具可以進行部分的測試設計、
實現(xiàn)、執(zhí)行和比較的工作。通過運用測試工具，可以達到提高測試效率的目的。
部分的測試工具可以實現(xiàn)測試用例的自動生成，但通常的工作方式為人工設計測
試用例，再通過工具進行測試用例的執(zhí)行和比較。因此，軟件測試自動化的設計
必須考慮實現(xiàn)利用工具進行用例的自動執(zhí)行等的特殊要求。
通過自動化測試，可以使某些任務提高執(zhí)行效率。除此之外，還有其它優(yōu)點：
·對程序的回歸測試更方便。這可能是自動化測試最主要的任務，特別是在
程序修改比較頻繁時，效果是非常明顯的。由于回歸測試的動作和用例是
完全設計好的，測試期望的結(jié)果也是完全可以預料的，將回歸測試自動運
行，可以極大提高測試效率，縮短回歸測試時間。
· 可以運行更多更繁瑣的測試。自動化的一個明顯的好處是可以在較少的時
間內(nèi)運行更多的測試。
·可以執(zhí)行一些手工測試困難或者手工不可能進行的測試。比如，對于大量
用戶的測試，不可能同時讓足夠多的測試人員同時進行測試，但是卻可以
通過自動化測試模擬同時有許多用戶，從而達到測試的目的。
·更好地利用資源。將繁瑣的任務自動化，可以提高準確性和測試人員的積
極性，將測試技術(shù)人員解脫出來投入更多精力設計更好的測試用例。有些
測試不適合于自動測試，僅適合于手工測試，將可自動測試的測試自動化
后，可以讓測試人員專注于手工測試部分，提高手工測試的效率。
·測試具有一致性和可重復性。由于測試是自動執(zhí)行的，每次測試的結(jié)果和
執(zhí)行的內(nèi)容的一致性是可以得到保障的，從而達到測試的可重復的效果。
·測試的復用性。由于自動測試通常采用腳本技術(shù)，這樣就有可能只需要做
少量的甚至不做修改，實現(xiàn)在不同的測試過程中使用相同的用例。
◆可以讓產(chǎn)品更快面向市場。自動化測試可以縮短測試時間，加快產(chǎn)品丌發(fā)
周期。
·增加軟件信任度。由于測試是自動執(zhí)行的，所以不存在執(zhí)行過程中的疏忽
和錯誤，完全取決于測試的設計質(zhì)量。一旦軟件通過了強有力的自動測試
后，軟件的信任度自然會增加。
總之，通過較少的開銷獲得更徹底的測試，提高軟件質(zhì)量，這是測試自動化
的最終目的。
軟件測試自動化要求一整套的測試工具組成一個完整的測試系統(tǒng)。一個自動
測試系統(tǒng)包含：
操作系統(tǒng)安全測評自動化的研究
·軟件測試管理的核心平臺。核心評估需要整合測試需求、測試計劃、測試
設計、測試實施、測試執(zhí)行到測試結(jié)果分析、測試報告的自動生成等整個
測試生命周期的管理活動。同時，統(tǒng)一組織各種Test Suite，Test Case，Test
Script，方便進行回歸測試?；貧w測試是在軟件維護階段，對修改之后的
軟件進行的測試。其目的是檢驗對軟件進行的修改是否正確。這里，修改
的正確性有兩重含義：一是所作的修改達到了預定目的，如錯誤得到改正，
能夠適應新的運行環(huán)境等等；二是不影響軟件的其他功能的正確性。
· 自動化功能測試。功能測試主要圍繞人機圖形窗口界面、字符終端和瀏覽
器界面進行測試。提供腳本方式自動測試目標的各個功能并生成測試報
告，甚至通過自動錄制形成測試腳本實現(xiàn)自動化的功能／回歸測試。
· 自動化壓力測試。自動化壓力測試工具主要目標是快速提升軟件測試團隊
的性能測試能力， 包括負載測試、壓力測試等等。應能方便靈活地模擬
各種負載模型，完成以查找響應時間瓶頸、系統(tǒng)吞吐量、最大并發(fā)虛擬用
戶等為目地的各種要求的性能測試；并且實現(xiàn)對壓力測試的測試需求、測
試計劃、測試設計、測試實施、測試執(zhí)行和測試結(jié)果分析等整個測試生命
周期的管理。
· 自動化的單元測試。自動化的單元測試要求模擬對象所需的運行環(huán)境，查
找代碼中的內(nèi)存滲漏及邏輯錯誤等等。
為了實現(xiàn)自動測試，人們提出了一些自動測試的方法，比較常見的有：
·模塊化測試腳本方法(Test Modularity Framework)。通過創(chuàng)建小而獨立的可
以描述的模塊、片斷以及待測應用程序的腳本，充分利用這些小模塊的重
用性，組合出所需的復雜測試。
·測試庫方法(Test Library Architecture)。測試庫方法與模塊化測試腳本方法
很類似，并且具有同樣的優(yōu)點。不同的是測試庫方法把待測應用程序分解
為過程和函數(shù)而不是腳本。這個方法需要創(chuàng)建描述模塊、片斷以及待測應
用程序的功能庫文件。
· 關(guān)鍵字驅(qū)動(Keyword—driven)或者表驅(qū)動(Table---driven)方法。這個方法
需要開發(fā)數(shù)據(jù)表和關(guān)鍵字，這些數(shù)據(jù)表和關(guān)鍵字獨立于執(zhí)行它們的測試自
動化工具并可以用來“驅(qū)動"待測應用程序和數(shù)據(jù)的測試腳本。在一個關(guān)
鍵字驅(qū)動測試中，把待測應用程序的功能和每個測試的執(zhí)行步驟一起寫到
一個表中。這個測試方法可以通過很少的代碼來產(chǎn)生大量的測試用例。同
樣的代碼在用數(shù)據(jù)表來產(chǎn)生各個測試用例的同時被復用。
·數(shù)據(jù)驅(qū)動測試方法(Data--driven)。數(shù)據(jù)驅(qū)動測試方法中，測試的輸入和輸
出數(shù)據(jù)是從數(shù)據(jù)文件中讀取(數(shù)據(jù)池數(shù)據(jù)庫CVS，excel文件等1，載入到通
27
北京交通大學碩士學位論文
過捕獲工具生成或者手工生成的代碼腳本中。在這個方法中，變量不僅被
用來存放輸入值還被用來存放輸出的驗證值。整個程序中，測試腳本來讀
取數(shù)值文件，記載測試狀態(tài)和信息。這類似于表驅(qū)動測試，但在表驅(qū)動測
試中，它的測試用例是包含在數(shù)據(jù)文件而不是在腳本中，對于數(shù)據(jù)而言，
腳本僅僅是一個“驅(qū)動器”，或者是一個傳送機構(gòu)。在數(shù)據(jù)驅(qū)動測試中，
數(shù)據(jù)文件中只包含測試數(shù)據(jù)，而不包含測試步驟。這個方法意圖是減少執(zhí)
行所有測試用例所需要的總的測試腳本數(shù)。
· 混合測試自動化(Hybrid Test Automation)方法。最普遍的執(zhí)行方法是上面
介紹的所有技術(shù)的一個結(jié)合，取其長處，彌補其不足。
3．2 操作系統(tǒng)安全測評自動化方法
鑒于安全操作系統(tǒng)的規(guī)模復雜性特征，其安全測評的工作量非常龐大。為此，
安全操作系統(tǒng)安全測評過程的自動化已成為當前安全操作系統(tǒng)研究領域的熱點方
向之一。毫無疑問，如果能夠?qū)崿F(xiàn)或部分實現(xiàn)安全測評過程的自動化，則對于改
善和提高安全操作系統(tǒng)的安全測評速度及質(zhì)量具有重要的現(xiàn)實意義和實用價值。
操作系統(tǒng)的測評自動化和軟件的測試自動化類似，是將測試設計、測試執(zhí)行
和結(jié)果判定所以步驟或其中的部分步驟的自動化。所以在以建立好的操作系統(tǒng)安
全測評方法的基礎上，操作系統(tǒng)安全測評自動化的主要工作就是測評自動化平臺
的構(gòu)建。
在本文完成時，對安全操作系統(tǒng)的測評及其自動化方法大多是探索性的，沒
有完整的理論體系。我們將在對以下兩種有代表性的安全操作系統(tǒng)安全測評實踐
進行分析。
3．2．1安全操作系統(tǒng)等級評測系統(tǒng)分析
2002年，魏丕會，卿斯?jié)h，黃建在國內(nèi)率先給出了安全操作系統(tǒng)等級評測系
統(tǒng)的設計——SLES【15】。該系統(tǒng)的目標是對不同的操作系統(tǒng)進行不同安全等級的自
動測評。
SLES系統(tǒng)的體系結(jié)構(gòu)如圖3．2所示，采用客戶端／測試服務器(數(shù)據(jù)庫服務器)
／待測系統(tǒng)3層結(jié)構(gòu)，在這3者之間采用兩個客戶機／服務器結(jié)構(gòu)，一個在客戶
端(引導評測員進行評測的終端，本系統(tǒng)利用瀏覽器束實現(xiàn))與測試服務器之間；一
個在測試服務器與待測系統(tǒng)之間。對于后者，該測試服務器相對于待測系統(tǒng)來說，
是待測系統(tǒng)的客戶端。
操作系統(tǒng)安全測評自動化的研究
圖3-2 SLES系統(tǒng)體系結(jié)構(gòu)
Figure 3-2 System structure ofSLES
由于在這3層結(jié)構(gòu)中，處于中間的測試服務器充當著兩個角色：服務器角色
與客戶機角色，因此它相應地完成3個功能：為瀏覽器端服務，對待測系統(tǒng)的安
全保護等級進行評測，以及對相應的數(shù)據(jù)進行處理。其中評測部分的功能負責完
成對待測系統(tǒng)的安全等級的評測，它接收來自瀏覽器端的信息，啟動相應的評測
程序和待測系統(tǒng)進行通信，對評測對象進行逐項評測，評測結(jié)束后把待測系統(tǒng)傳
回的評測結(jié)果寫入后臺數(shù)據(jù)庫；而數(shù)據(jù)處理功能負責處理相應的數(shù)據(jù)處理請求，
如接收客戶端應用程序的處理數(shù)據(jù)的請求，對相關(guān)數(shù)據(jù)進行查詢、修改等操作，
以及最后把由評測程序處理完的結(jié)果返回給瀏覽器端。而客戶端利用瀏覽器方式
引導評測員完成評測，包括人機交互的所有信息和評測的整個流程控制。客戶端
應用程序還要與服務器端應用程序進行通信，生成報表。設計安全操作系統(tǒng)評測
系統(tǒng)必需要解決的一個問題就是對不同操作系統(tǒng)的評測，因為操作系統(tǒng)的實現(xiàn)各
不相同。為此SELS評測系統(tǒng)規(guī)則分為兩層：一是用戶層，這是固定的一層，是對
用戶評測請求的抽象表示，提供進行評測所需要的用戶層評測命令，一般這一層
不會改變；另一層是操作系統(tǒng)相關(guān)層，這一層和操作系統(tǒng)相關(guān)，是用戶層規(guī)則的
基于操作系統(tǒng)的表示，這一層的內(nèi)容會隨著操作系統(tǒng)的不同而動態(tài)調(diào)整。對安全
操作系統(tǒng)的任何一步評測最后都要歸結(jié)為相應的操作系統(tǒng)相關(guān)層指令的運行。
SLES系統(tǒng)對操作系統(tǒng)安全保護等級的評測經(jīng)由客戶端發(fā)起，首先由評測人員
根據(jù)操作系統(tǒng)開發(fā)商的申請選擇相應的安全等級，系統(tǒng)會給出該等級所對應的安
全功能和安全保證，接著SLES系統(tǒng)針對每個安全功能產(chǎn)生對應的評測矢量，安全
評測工具通過評測矢量，生成特定評測對象使用的評測驅(qū)動，由評測驅(qū)動在評測
環(huán)境中運行，給出安全功能評測結(jié)果；而對安全保證的評測則主要通過評測人員
根據(jù)相應的保證條款作出相應的選擇，系統(tǒng)會提示給出相應的安全保證條款，由
北京交通大學碩士學位論文
評測人員選擇，向評測程序傳送相應的結(jié)果，然后，安全評測工具通過分析評測
驅(qū)動給出的評測結(jié)果(包括安全功能評測結(jié)果和安全保證評測結(jié)果)確定評測對象
的安全特性，同時確定該評測對象，即操作系統(tǒng)的安全等級。
為了解決對不同操作系統(tǒng)評測的問題，SLES引入了規(guī)則的概念。SLES系統(tǒng)
中任何一步評測都是由規(guī)則來指導進行的，在這里，規(guī)則是指導評測系統(tǒng)進行評
測的指令集合。因為安全操作系統(tǒng)之間的千差萬別，對規(guī)則的設計采取了分層的
概念。評測系統(tǒng)規(guī)則分為兩層：一是用戶層，這是固定的一層，是對用戶評測請
求的抽象表示，提供進行評測所需要的用戶層評測命令，一般這一層不會改變；
另一層是操作系統(tǒng)相關(guān)層，這一層和操作系統(tǒng)相關(guān)，是用戶層規(guī)則的基于操作系
統(tǒng)的表示，這一層的內(nèi)容會隨著操作系統(tǒng)的不同而動態(tài)調(diào)整。對安全操作系統(tǒng)的
任何一步評測最后都要歸結(jié)為相應的操作系統(tǒng)相關(guān)層指令的運行。
SLES評測系統(tǒng)的核心是測評服務器，它是根據(jù)規(guī)則具體執(zhí)行評測的模塊。評
測員向系統(tǒng)提出了測評請求，這些請求被轉(zhuǎn)化成相應的用戶層規(guī)則，送到測評服
務器，測評程序服務器會根據(jù)這些用戶層規(guī)則去查詢一個數(shù)據(jù)庫(命令映射庫)，這
個數(shù)據(jù)庫保存了用戶層命令和操作系統(tǒng)命令的對應關(guān)系，測評程序服務器將這些
用戶層規(guī)則轉(zhuǎn)化成操作系統(tǒng)相關(guān)層規(guī)則，這些操作系統(tǒng)相關(guān)層規(guī)則就是指導評測
服務器進行評測的動作代碼，評測服務器根據(jù)動作代碼完成評測動作，得到評測
結(jié)果并且返回。
因為對規(guī)則進行分層，操作系統(tǒng)相關(guān)層規(guī)則是和被評測的操作系統(tǒng)相關(guān)的，
所以才能夠?qū)Ω鞣N不同的安全操作系統(tǒng)進行評測。每次對一個新的操作系統(tǒng)進行
測試，都要由測試員進行規(guī)則數(shù)據(jù)庫的更新。
評測程序服務器的體系結(jié)構(gòu)如圖3．3所示，包括一個控制中心、一個評測規(guī)則
轉(zhuǎn)化模塊和一個評測執(zhí)行模塊。
規(guī)則轉(zhuǎn)化模塊
用
戶 相操
層 關(guān)作
規(guī)系
規(guī)
則 則統(tǒng) 1
日戶層規(guī)財
榨匍中。心
測評結(jié)果
圖3-3 SLES測評程序服務器模塊
Figure 3-3 Evaluation process server model of SLES
規(guī)制轉(zhuǎn)化模塊是整個系統(tǒng)的動態(tài)部分，保存用戶層規(guī)則和操作系統(tǒng)相關(guān)規(guī)則
的對應，需要根據(jù)不同的操作系統(tǒng)進行動態(tài)配置，SLES根據(jù)這個數(shù)據(jù)庫才能知道
對于這個特定的操作系統(tǒng)進行評測所需要的具體指令集合。這個規(guī)制轉(zhuǎn)化模塊實
操作系統(tǒng)安全測評自動化的研究
現(xiàn)了用戶層規(guī)則到操作系統(tǒng)相關(guān)層規(guī)則的轉(zhuǎn)化。
優(yōu)點：
● 在分級測試中，通過國標中的安全功能組件和測評等級的對應來決定不同
級別測試的測試內(nèi)容。
· 通過引入規(guī)則的概念，解決了對不同操作系統(tǒng)的測評的跨平臺的問題。
缺點：
·沒有解決測評中的關(guān)鍵問題——安全測評標準中的安全功能組件怎樣對
應為具體的測試用例、測試命令的問題。文章中提到SLES系統(tǒng)針對每個
安全功能產(chǎn)生對應的評測矢量，生成特定評測對象使用的評測驅(qū)動，由評
測驅(qū)動在評測環(huán)境中運行，給出安全功能評測結(jié)果。作者沒有說明評測矢
量、評測驅(qū)動的定義，而且安全測評標準中的安全功能組件非常抽象，和
測評用例、測試命令之間還有很大差距。
· 由于系統(tǒng)自動化程度目標較高，實現(xiàn)起來較為困難。
3．2．2數(shù)據(jù)驅(qū)動的自動化測評系統(tǒng)分析
2005年陸幼驪，張紅旗提出了基于數(shù)據(jù)驅(qū)動的操作系統(tǒng)安全測評系統(tǒng)【71。介
紹了一個UNIX／Linux安全測評系統(tǒng)的設計，該系統(tǒng)基于數(shù)據(jù)驅(qū)動方法實現(xiàn)來測評
過程的自動化。
文章指出，標準是測評的靈魂，安全標準提供了每一個安全等級所對應的安
全功能的技術(shù)要求，但是由于各個操作系統(tǒng)具有不同的實現(xiàn)，安全標準不可能制
訂出明確、詳細的工程技術(shù)指標，而只能是一個綜述性的說明。同時，由于操作
系統(tǒng)結(jié)構(gòu)復雜，那種根據(jù)安全標準進行對照檢查式的測評方法不可行，安全測評
的技術(shù)難度在于如何設計從標準到測試用例的映射關(guān)系。對操作系統(tǒng)的安全測評
就是檢查安全機制是否完整地實現(xiàn)了安全策略。
圖
圖3．4數(shù)據(jù)驅(qū)動的自動化測評系統(tǒng)結(jié)構(gòu)
Figure 3—4 Structure of data-driven automated evaluation system
自動化測評系統(tǒng)由以下幾個功能模塊所組成，如圖3．4所示。知識庫：用于
31
北京交通大學碩士學位論文
存放測試數(shù)據(jù)、控制數(shù)據(jù)、測試預期結(jié)果和測試結(jié)果。組件庫：用于存放測試腳
本。支持庫：用于存放通用例程。驅(qū)動引擎：是整個測評框架的核心部分，驅(qū)動
測試的發(fā)生。驅(qū)動表集：用于存放驅(qū)動表格。評估器：根據(jù)測試結(jié)果生成評估報
告。控制端：用于人員與測評系統(tǒng)的交互。測試端：測試套件與被測操作系統(tǒng)進
行數(shù)據(jù)傳遞的端口。測試的發(fā)起源于用戶的申請，控制端用該請求激發(fā)核心數(shù)據(jù)
驅(qū)動引擎，使引擎根據(jù)驅(qū)動表集中的測試驅(qū)動表格依次從知識庫中取出測試數(shù)據(jù)、
從組件庫和支持庫中取出測試腳本和通用例程，從而形成符合用戶需求的一個自
動化測試套件，該套件通過測試端對操作系統(tǒng)的測試后將測試結(jié)果放回知識庫，
由評估器根據(jù)知識庫中的預期結(jié)果，與測試結(jié)果進行比較，并依據(jù)測評標準生成
測評報告以提交給用戶。
該系統(tǒng)以自動化測評框架為基礎，該框架基于數(shù)據(jù)驅(qū)動測試的思想而建立。
通過數(shù)據(jù)抽象將測試數(shù)據(jù)與測試腳本本身分離開，并將其包含在測試數(shù)據(jù)文件中，
測試腳本的功能及執(zhí)行由外部測試數(shù)據(jù)所引導。測試數(shù)據(jù)包括控制數(shù)據(jù)和測試輸
入數(shù)據(jù)，其中控制數(shù)據(jù)用于設置測試環(huán)境和導航被測操作系統(tǒng)，而測試輸入數(shù)據(jù)
用于提交給測試腳本來測試操作系統(tǒng)的安全性。結(jié)構(gòu)化的測試腳本被設計成從數(shù)
據(jù)文件讀取測試數(shù)據(jù)記錄，然后執(zhí)行以數(shù)據(jù)記錄內(nèi)容為基礎的動作，每個數(shù)據(jù)記
錄處理完后， 控制返回到測試循環(huán)的起點以讀取下一個記錄，測試將繼續(xù)進行直
到?jīng)]有數(shù)據(jù)記錄要處理。
驅(qū)動機制采用的是多級表格驅(qū)動的數(shù)據(jù)驅(qū)動實現(xiàn)機制，系統(tǒng)的體系結(jié)構(gòu)中包
括驅(qū)動測試的表格集合的層次構(gòu)建。這些表包括三種類型的驅(qū)動表格：套件驅(qū)動
表格、循環(huán)驅(qū)動表格和步進驅(qū)動表格。循環(huán)、套件和步進三種驅(qū)動表分別對應了
測試的三個層次，也代表了測試數(shù)據(jù)的抽象程度，其中套件驅(qū)動的抽象程度最高，
它表示了一個測試需求(用戶的一次測試申請)。循環(huán)驅(qū)動表是中級驅(qū)動，每一張循
環(huán)驅(qū)動表應用于一項安全功能(機制)的測試需求。步進驅(qū)動的抽象程度最小，它描
述了一個具體的測試動作(一個測試用例的運行)。
優(yōu)點：
·利用了軟件測試自動化中的模塊化測試腳本方法，將編寫好的測試腳本和
測試例程存儲在組件庫和支持庫中，充分利用里這些腳本的重用性。
·利用軟件測試自動化中的數(shù)據(jù)驅(qū)動的方法，實現(xiàn)測試需求到測試數(shù)據(jù)再到
測試動作的轉(zhuǎn)化。該測試數(shù)據(jù)就相當于測試用例，是手動編寫的。彌補了
SLES系統(tǒng)不能將安全功能需求和測試用例對應的問題。
缺點：
·給出系統(tǒng)設計過于概括，對怎樣利用數(shù)據(jù)驅(qū)動方法實現(xiàn)從用戶的測試申請
到測試動作的轉(zhuǎn)化沒有介紹，實現(xiàn)起來較為困難。
32
操作系統(tǒng)安全測評自動化的研究
◆只適用于一種操作系統(tǒng)，測試不同的操作系統(tǒng)時測試腳本、測試例程、驅(qū)
動表需要重新建立。
3．2．3操作系統(tǒng)安全測評自動化方法總結(jié)
因為各個標準對操作系統(tǒng)安全等級的劃分只是給出了一個最終的實現(xiàn)目標，
并沒有從實現(xiàn)方法上給予規(guī)定，這就導致了安全操作系統(tǒng)的具體實現(xiàn)千差萬別，
制定一個完全自動的評測系統(tǒng)在現(xiàn)階段是不夠現(xiàn)實的也是不可能的。
操作系統(tǒng)測評自動化方法大都利用了軟件測試自動化的方法。
操作系統(tǒng)測評自動化過程中需要解決的幾大重要問題：
·怎樣將安全標準中的安全功能需求映射成為測試用例；
·怎樣自動的執(zhí)行測試用例；
· 怎樣實現(xiàn)測評自動化工具的跨平臺性。
每一個問題都是非常復雜和探索性的，所以操作系統(tǒng)安全測評自動化是個復
雜而又艱難的過程。
在總結(jié)了以上兩個典型的操作系統(tǒng)測評自動化系統(tǒng)和融合了之前總結(jié)的軟件
測試自動化理論和技術(shù)的基礎上，我們提出了一種改進的操作系統(tǒng)自動化測評框
架———OSSEF。
3．3 操作系統(tǒng)安全測評自動化框架——OSSEF
OSSEF(Operating System Security Evaluation Framework)是一個改進后的
操作系統(tǒng)安全測評自動化框架，它吸收了上述操作系統(tǒng)測評自動化系統(tǒng)的優(yōu)點和
利用了一些軟件測試自動化方法：一、將測評請求先映射為相應的安全測評準則
中的安全功能組件，再將這些組件映射為測試用例；二、借鑒了上面介紹的第一
種安全測評自動化系統(tǒng)中的“規(guī)則"的概念，通過轉(zhuǎn)化規(guī)則自動將測試用例轉(zhuǎn)化
成測試腳本，這種方法較之上面介紹的第二種安全測評自動化系統(tǒng)的三級驅(qū)動在
實現(xiàn)方法上簡單，而且代替了其直接編寫測試腳本的方式，減小了工作量；三、
利用了數(shù)據(jù)驅(qū)動方法，將測試用例中重復部分的數(shù)據(jù)和測試用例分離。OSSEF的總
體思想是根據(jù)不同等級的安全功能需求手動進行測試用例設計并用特定語言和格
式描述，測試用例的編寫可以借助用例管理工具進行，編寫好的測試用例將存儲
在數(shù)據(jù)庫中，測評等級與安全功能組件的對應關(guān)系及安全功能組件與測試用例的
對應關(guān)系也存儲在數(shù)據(jù)庫中，用戶提出測評請求后測評框架通過這些映射關(guān)系從
數(shù)據(jù)庫中讀取測試用例，在用例解釋器的幫助下將測試用例和測試數(shù)據(jù)轉(zhuǎn)化成測
33
北京交通大學碩士學位論文
試腳本，執(zhí)行測試腳本并收集測試結(jié)果，待所有的測試用例測試完成后，進行測
評結(jié)果的判定。
3．3．1總體設計
OSSEF的體系結(jié)構(gòu)如圖3—5所示。OSSEF分為測評客戶端、測評引擎和數(shù)據(jù)庫
三大部分。測評客戶端是測評人員進行測評的入口，在測評客戶端中，測評人員
可以選擇測評等級，或者選擇Iii貝I評等級更細一層的測評組件，之后發(fā)起測評。
測評引擎接受到測評請求后，通過測評執(zhí)行器訪問數(shù)據(jù)庫，取得測評組件對應的
測試用例和測試用例所需要的測試數(shù)據(jù)，并在用例解釋器的幫助下生成測試腳本，
測評執(zhí)行器執(zhí)行測試腳本并收集測試結(jié)果，執(zhí)行完所有的測試用例后對結(jié)果進行
判定并將測評結(jié)果返回給測評客戶端，這樣測評人員就得到了測評結(jié)果。
圖3．5 OSSEF框架的結(jié)構(gòu)
Figure 3-5 Structure of OSSEF
在國標GB／T18336—200l和TCSEC中對安全功能進行了等級劃分，但是沒有具
體規(guī)定具體安全功能需求組件，而CC標準提供了安全功能需求組件，于是我們通
過分析國標中安全等級的安全要求和CC標準中安全功能組件的目的實現(xiàn)兩者的映
射，即如圖3-6所示的映射關(guān)系。
么第一級≥≤第二芳級 ≥第≮二級 7＼◇ FAI UAU．1 FAI—UAU．2 FAI UAU．3 FAI UAU．4 FAI UAU．5 ／＼
FAI UAU．4．1 FAI—UAU．4．2
圖3-6測評等級和安全功能組件的映射關(guān)系
Figure 3-6 Relation between evaluation level and security functional components
操作系統(tǒng)安全測評自動化的研究
圖中的安全功能需求組件的內(nèi)容是：
FIA-UAU．1：計算機信息系統(tǒng)可信計算基初始執(zhí)行時，首先要求用戶標識自己
的身份，并使用保護機制(例如：口令)來鑒別用戶的身份；
FI圳AU．2：阻止非授權(quán)用戶訪問用戶身份鑒別數(shù)據(jù)；
FIA_UAU．4：計算機信息系統(tǒng)可信計算基還具備將身份標識與該用戶所有可審
計行為相關(guān)聯(lián)的能力。
以功能元素FIA_UAU．4組件為例，又可分為功能子項(僅舉兩個為例)：
FIA-UAU．4．1：審計以非法密碼登錄的錯誤；
FIA-UAU．4．2：申請以非法安全級登錄的錯誤；
國標中安全等級的第一級是用戶自主保護級，這一級的安全功能需求是：計
算機信息系統(tǒng)可信計算基定義和控制系統(tǒng)中命名用戶對命名客體的訪問。實施機
制(例如：訪問控制表)允許命名用戶以用戶和(或)用戶組的身份規(guī)定并控制
客體的共享；阻止非授權(quán)用戶讀取敏感信息。計算機信息系統(tǒng)可信計算荃初始執(zhí)
行時，首先要求用戶標識自己的身份，并使用保護機制(例如：口令)來鑒別用
戶的身份，阻止非授權(quán)用戶訪問用戶身份鑒別數(shù)據(jù)。計算機信息系統(tǒng)可信計算墓
通過自主完整性策略，阻止非授權(quán)用戶修改或破壞敏感信息。所以安全等級的第
一級應該和圖中FIA UAU．1和FIA UAU．2對應。同理每一個安全等級都可以和具
體的安全需求組件對應。
在進行了框架的總體設計后，我們進行框架的詳細設計，包擴數(shù)據(jù)庫內(nèi)容設
計、用例管理工具設計、測評引擎設計、測試用例解釋器設計以及OSSEF的測評
流程。
3．3．2數(shù)據(jù)庫內(nèi)容設計
數(shù)據(jù)庫內(nèi)容的設計如圖3—7所示。數(shù)據(jù)庫中存放的內(nèi)容包括測評等級與安全
功能組件的對應關(guān)系、安全功能組件測試用例的對應關(guān)系以及測試用例和測試用
例需要的測試數(shù)據(jù)。測試用例以文件形式存儲，對應關(guān)系以二維表的形式存儲。
測評引擎接收到測評的指令后通過測評等級和組件對應關(guān)系表找到需要需要測評
的安全組件，再通過安全組件與測試用例的對應關(guān)系將測試用例按順序取出進行
測試。由于測試用例中重復部分的測試數(shù)據(jù)被提取出來放，所以要將這些測試數(shù)
據(jù)和測試數(shù)據(jù)與測試用例的對應關(guān)系也存儲在數(shù)據(jù)庫中。
35
北京交通大學碩士學位論文
測評等級安全功能需求組件測試用例
3．3．3用例管理器設計
圖3．7數(shù)據(jù)庫內(nèi)容
Figure 3-7 Content of the Data Base
經(jīng)過可行性分析我們認為測試用例的自動化生成是不具可行性的，所以在
0SSEF中，我們對測試用例的生成采用測評人員手動編寫測試用例的方式。為了減
輕測評人員的負擔和提高工作效率我們設計了用例管理器對測試用例進行管理。
為了能讓測試引擎理解并執(zhí)行測試用例，測試用例必須用一種容易理解同時
又標準化、結(jié)構(gòu)化的形式來表述。XML語言就是這樣一種語言，而且各種平臺和語
言對對XML語言有很好的支持，便于框架的實現(xiàn)。所以0SSEF的測試用例用XML
語言描述。
用例管理器以圖形界面的形式幫助測評人員對測試用例進行添加、刪除、編
輯、查找以及添加、刪除、修改測試用例及安全功能組件與測試用例的對應關(guān)系。
3．3．4測評引擎設計
測試引擎設計如圖3—8所示。測評引擎包括測評執(zhí)行器、用例解釋器。測評
執(zhí)行器又分為三部分，分別是測試數(shù)據(jù)提取模塊、測試執(zhí)行模塊和測試用例到測
試測試腳本轉(zhuǎn)化模塊。
由于測評執(zhí)行器會從數(shù)據(jù)庫中反復查找測試用例和測試數(shù)據(jù)，查找過程是重
復的，所以我們將測試數(shù)據(jù)提取作為一個測評執(zhí)行器和數(shù)據(jù)庫的接口模塊，它可
以根據(jù)測評執(zhí)行器的請求從數(shù)據(jù)庫中提取所需的測試用例和測試數(shù)據(jù)。
操作系統(tǒng)安全測評自動化的研究
圖3-8測試引擎結(jié)構(gòu)
Figure 3-8 Structure of testing engine
測試用例和最終的測試命令還有很大差距，還不能直接作用于待測系統(tǒng)，用
例解釋器就是用例告訴測試用例到測試腳本轉(zhuǎn)化模塊怎樣將測試用例轉(zhuǎn)化為測試
腳本(測試命令序列)。實際上測試用例解釋器是一組轉(zhuǎn)化規(guī)則的集合，這組規(guī)則
的作用類似于解釋器。這些規(guī)則需要專業(yè)人員手動編制，對一種操作系統(tǒng)來說這
些規(guī)則一旦編制完成一般不需要改動。這樣設計好處是，一、測試用例編寫人員
只需要考慮操作系統(tǒng)的安全功能來設計用例，不用考慮底層的測試命令；二、如
果待測系統(tǒng)有所變動只需要改變規(guī)則，保證了測試用例的通用性；三、測試用例
的修改可以通過用例管理器進行，比修改測試腳本更方便。
測試執(zhí)行器將轉(zhuǎn)化好的測試腳本中的測試命令傳給測試執(zhí)行模塊進行具體的
測試執(zhí)行，測試執(zhí)行模塊會將捕捉待測系統(tǒng)的測試結(jié)果，告知測評執(zhí)行器。測評
執(zhí)行器還將進行測試結(jié)果和預期結(jié)果比對發(fā)送給測評客戶端，測評客戶端會將最
終的測評結(jié)果反饋給測評人員。
3．3．5 OSSEF測評步驟
0SSEF的具體測評步驟如下：
(1)測評人員將OSSEF安裝在待測系統(tǒng)中，專業(yè)人員根據(jù)待測系統(tǒng)編制用
例解釋器中的轉(zhuǎn)化規(guī)則。
(2)測評人員通過測評客戶端提出測評請求，輸入測評等級。測評客戶端
將測評請求發(fā)送給測評引擎中的測評執(zhí)行器。
(3)測評執(zhí)行器通過測評數(shù)據(jù)提取模塊從數(shù)據(jù)庫中取出該測評等級相關(guān)的
測試用例和測試數(shù)據(jù)。
北京交通大學碩十學位論文
(4)測試用例到測試流轉(zhuǎn)化模塊模塊通過用例解釋器中的規(guī)則將測試用例
轉(zhuǎn)化為測試流。
(5)測試流執(zhí)行模塊執(zhí)行測試腳本中的測試命令并將測試結(jié)果返回給測評
執(zhí)行器，測評執(zhí)行器進行測試結(jié)果和預期結(jié)果的比對。
(6)重復執(zhí)行第3步到第5步，直到執(zhí)行完該測評等級的所有測試用例。
測評執(zhí)行器將所有用例的測試結(jié)果對比發(fā)送給測評客戶端，測評人員
根據(jù)此結(jié)果給出對待測系統(tǒng)的等級評定。
3．3．6技術(shù)難點及解決方案討論
前面我們只是給出了0SSEF的設計，在具體的實現(xiàn)過程中還存在很多技術(shù)難
點，下面我們對這些技術(shù)難點進行討論。
●測試用例在數(shù)據(jù)庫中的存放。為了便于讀取整個測試用例文件，應該將每
個測試用例以文件的形式存儲在數(shù)據(jù)庫中，并為所有的測試用例在數(shù)據(jù)庫
中建立相應的信息數(shù)據(jù)。
●測試引擎的跨平臺性。在測評前需要先將0SSEF安裝在待測系統(tǒng)中，這就
要求0SSEF有很好的跨平臺性，由于Java有良好的跨平臺性，可以用Java
來實現(xiàn)0SSEF的測評客戶端和測評引擎的。
·底層測試。操作系統(tǒng)提供給用戶的接口不僅是用戶命令，還可能有系統(tǒng)調(diào)
用等，系統(tǒng)調(diào)用的測試不能用測試命令實現(xiàn)，可以用C語言編寫并編譯為
二進制程序用來測試。
· 測試用例和測試命令的對應關(guān)系。測試用例和測試流的對應關(guān)系是應該通
過分析待測系統(tǒng)的功能和用戶接口來得出。由于不同操作系統(tǒng)之間可能有
很大差異，所以測試用例和測試命令的對應關(guān)系也就是轉(zhuǎn)化規(guī)則隨著系統(tǒng)
的不同而不同，所以在對不同操作系統(tǒng)進行測評前，需要建立新的修改轉(zhuǎn)
化規(guī)則關(guān)系。
3．4 小結(jié)
本章分析了軟件測試自動化的理論和國內(nèi)現(xiàn)有的兩種的操作系統(tǒng)安全測評自
動化系統(tǒng)結(jié)構(gòu)并對這些系統(tǒng)的優(yōu)缺點進行了評價，在吸取了這些系統(tǒng)的優(yōu)點和融
合了軟件測試自動化方法的基礎上，給出了改進后的操作系統(tǒng)安全測評自動化框
架的設計方案和技術(shù)難點的解決方案的討論。
38
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
4 Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
操作系統(tǒng)安全測試自動化的是安全測評自動化的基礎。操作系統(tǒng)安全測試自
動化是個復雜而又艱難的過程，需要大量的人力物力來完成，因此我們不可能對
整個操作系統(tǒng)進行自動化測試。于是我們將從訪問控制功能這個操作系統(tǒng)中最重
要的安全機制出發(fā)，對操作系統(tǒng)安全測試自動化進行實踐。又因為國內(nèi)自主研發(fā)
的操作系統(tǒng)大多基于開源的Linux系統(tǒng)內(nèi)核，所以對Linux系統(tǒng)測試自動化方法的
研究和工具的實現(xiàn)有很強通用性和實用價值。由于上述原因，我們設計和實現(xiàn)了
Linux訪問控制安全測試自動化工具。這一章將對工具的設計思路和實現(xiàn)方法予以
詳細的介紹。
4．1 Linux系統(tǒng)的自主訪問控制機制分析
對操作系統(tǒng)的一項安全機制實現(xiàn)測試自動化，第一步先要分析該機制提供的
安全功能；第二步應該分析從那些方面測試這些安全功能，這一步可參考測評標
準中的相關(guān)安全功能組件中的具體描述來確定；第三步是測試用例設計；第四步
是自動化測試工具的設計與實現(xiàn)；第五步是測試自動化工具的運行，即測試執(zhí)行
和結(jié)果輸出的過程。下面我們來分析Linux系統(tǒng)自主訪問控制機制。
4．1．1 UG0訪問控制管理機制
UGO(User、Group、Other)訪問控制機制是UNIX文件系統(tǒng)傳統(tǒng)的訪問控制
方式，它通過在文件和目錄上都設置權(quán)限位，用來控制用戶對文件或目錄的訪問。
UGO訪問控制方式也是Linux系統(tǒng)最基本的訪問控制安全機制【211。
在UGO訪問控制方式中，一個文件創(chuàng)建后，它具有讀、寫和執(zhí)行三種操作方
式，文件的操作者分為文件所有者、同組用戶和其他用戶三類。文件所有者是指
創(chuàng)建文件的用戶，他是文件的擁有者，他可以設置用戶的讀、寫和執(zhí)行權(quán)限，也
就是說他是訪問控制權(quán)限的決定者。文件建立時默認的用戶組是文件所有者所在
的用戶組，但文件所有者可以對該用戶組進行修改，該組中的所有用戶都是文件
的同組用戶。
UGO訪問控制方式將文件的權(quán)限用三組3位的二進制位描述，即9位二進制數(shù)，
并且在最前面加上一位作為文件的類型標志。每類用戶占3位，讀、寫、執(zhí)行權(quán)限
各用1位描述，具有權(quán)限時，該位就設置為1。讀、寫、執(zhí)行權(quán)限分別用r、w、x三
39
北京交通大學碩+學位論文
個字符表示。
除了這9位權(quán)限位UGO訪問控制方式還有SUID、SGID和sticky---個特殊權(quán)限
位。它們位于9位權(quán)限位之前。如果一個文件被設置了SUID或SGID位，會分別表
現(xiàn)在所有者或同組用戶的權(quán)限的可執(zhí)行位上。例如：．rwsr．xr-x表示SUID和所有
者權(quán)限中可執(zhí)行位被設置；．rwSr-．r一表示SUID被設置，但所有者權(quán)限中可執(zhí)行位
沒有被設置；．rwxr．sr．x表示SGID矛11同組用戶權(quán)限中可執(zhí)行位被設置；．rw-r-Sr--表
示SGID被設置，但同組用戶權(quán)限中可執(zhí)行位沒有被設置。SUID年BSGID僅可用在
二進制文件上，不能用在批處理文件(shell腳本)上，設置其他種類文件的SUID
和SGID位是沒有意義的。如果一個程序設置了SUID，執(zhí)行程序的用戶的euid和
egid變成被運行的程序的所有者I拘uid和百d，這個進程將擁有該程序的所有者對資
源的訪問權(quán)限。同理，設置了SGID后，進程將擁有該程序所屬組對資源的訪問權(quán)
限。如果SUID和SGID同時開啟，貝IJSUID的優(yōu)先權(quán)高于SGID。但SGID對文件的所
有者不起作用。Sticky只對文件夾有作用，其作用是如果文件夾設置TSticky，即
使對文件夾有寫權(quán)限也不能刪除該文件夾中所有者不是自己的文件或文件夾。
4．1．2 ACL訪問控制管理機制
由于UGO訪問控制方式只能對文件所有者、同組用戶和其它用戶進行進行訪
問控制，很難對每個用戶或用戶組進行訪問控制，即訪問控制粒度過粗，導致了
ACL的產(chǎn)生。ACL的作用是控制單個用戶和用戶組指定文件訪問權(quán)限【211。
ACL(Access Control List，訪問控制列表)基于IEEE POSIX 1003．1e標準，
EXT2、EXT3、EXT4、JFS、XFS和ReiserFS等文件系統(tǒng)都支持ACL。
ACL的優(yōu)先級高于UGO的優(yōu)先級，當ACL的權(quán)限設置大于UGO時，mask就是
UGO權(quán)限中的同組用戶的最高權(quán)限，而ACL的有效權(quán)限則是和mask取權(quán)限的交集，
從而限制了ACLXiJUGO權(quán)限的超越。但文件的所有者可以通過修改mask值來消除
這種限制。在測試時，為了保證ACL訪問控制不受限于UGO訪問控制，應得將mask
值設為IWX。ACL中單個用戶權(quán)限的優(yōu)先權(quán)高于同組用戶權(quán)限，也就是說如果在
ACL中設置了某個用戶的權(quán)限，又設置了這個用戶所在組的用戶權(quán)限，則這個用
戶的權(quán)限與他所在組的用戶權(quán)限無關(guān)。例如，文件file的所有者為Userl，User2所
在的用戶組為Group2，我們設置User2對file文件的AC呶限為rw．，又設置用戶組
Group2對的文件file的ACL權(quán)限為卜，那么User2對文件file的權(quán)限為I'W．，不受
Group2用戶組權(quán)限的影響。ACL對文件所有者的權(quán)限不起作用，只對所有者外的
用戶權(quán)限和組權(quán)限起作用，當設置了文件所有者的AC呶限后，文件所有者對文
件的訪問控制4仍然按照UGO權(quán)限實施。
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
4．2 Linux訪問控制安全功能要求及測試方法設計
4．2．1安全功能要求
CC標準中與訪問控制中有關(guān)自主訪問控制的安全功能組件的內(nèi)容如下：
FDP ACC．2．1測評對象的安全功能應對的任意的主體和客體以及它們之間的
操作執(zhí)行自主訪問控制策略。該安全組件要求測評對象的安全功能能夠保證客體
的所有者可以按照自己的意愿精確地指定系統(tǒng)中的主體對此客體的訪問權(quán)，強調(diào)
的是自主訪問控制策略的功能性。
FDP ACC．2．2測評對象的安全功能應確保所有主體和客體之間的所有操作將
被自主訪問控制策略所覆蓋。該安全組件要求測評對象的安全功能能夠保證自主
訪問控制能夠?qū)嵤┯谒械闹黧w和客體以及它們之間所有操作，強調(diào)自主訪問控
制策略的覆蓋性。
4．2．2測試方法設計
測試方法是安全測試的重要內(nèi)容。操作系統(tǒng)安全測試和軟件功能的測試方法
不盡相同。在分析了Linux系統(tǒng)的系統(tǒng)結(jié)構(gòu)的基礎上，我們得出對安全功能的測試
應該從兩方面進行，一是系統(tǒng)底層Linux系統(tǒng)調(diào)用的安全功能測試，二是Shell安
全功能測試。
用戶空間
系統(tǒng)空間
圖4-1 Linux系統(tǒng)空間與用戶空間
Figure 4-1 System space and user space of Linux
系統(tǒng)調(diào)用測試：
Linux安全機制的實施機構(gòu)是系統(tǒng)內(nèi)核，如圖4-1所示，Shell和用戶程序都建
立在內(nèi)核之上的，都工作在用戶態(tài)。進入內(nèi)核的唯一方法是通過系統(tǒng)調(diào)用。系統(tǒng)
調(diào)是操作系統(tǒng)提供給用戶程序調(diào)用的一組“特殊"接口，用戶程序可以通過這組
“特殊”接口來獲得操作系統(tǒng)內(nèi)核提供的服務，比如用戶可以通過文件系統(tǒng)相關(guān)
的調(diào)用請求系統(tǒng)打開文件、關(guān)閉文件或讀寫文件，可以通過時鐘相關(guān)的系統(tǒng)調(diào)用
41
北京交通大學碩士學位論文
獲得系統(tǒng)時間或設置系統(tǒng)時間等【221。
系統(tǒng)服務之所以需要通過系統(tǒng)調(diào)用提供給用戶空間的根本原因是為了對系統(tǒng)
“保護”，因為Linux的運行空間分為內(nèi)核空間與用戶空間，它們各自運行在不同
的級別中，邏輯上相互隔離。所以用戶進程在通常情況下不允許訪問內(nèi)核數(shù)據(jù)，
也無法使用內(nèi)核函數(shù)，它們只能在用戶空間操作用戶數(shù)據(jù)，調(diào)用戶用空間函數(shù)。
很多情況下，用戶進程需要獲得系統(tǒng)服務就必須利用系統(tǒng)提供給用戶的“特殊”
接口——系統(tǒng)調(diào)用了，它的特殊性主要在于規(guī)定了用戶進程進入內(nèi)核的具體位置，
換句話說用戶訪問內(nèi)核的路徑是事先規(guī)定好的，只能從規(guī)定位置進入內(nèi)核，而不
準許肆意跳入內(nèi)核。有了這樣的陷入內(nèi)核的統(tǒng)一訪問路徑限制才能保證內(nèi)核安全。
并不是所有的功能都是在內(nèi)核實現(xiàn)的，也就是不是所有的服務都存在于內(nèi)核。
什么樣的服務應該由內(nèi)核完成并沒有明確的答案。選擇在內(nèi)核完成通?；谝幌?
考慮：
·服務必須獲得內(nèi)核數(shù)據(jù)，比如一些服務必須獲得中斷或系統(tǒng)時間等內(nèi)核數(shù)
據(jù)。
·從安全角度考慮，在內(nèi)核中提供的服務相比用戶空間提供的毫無疑問更安
全，很難被非法訪問到。
·從效率考慮，在內(nèi)核實現(xiàn)服務避免了和用戶空間來回傳遞數(shù)據(jù)以及保護現(xiàn)
場等步驟，因此效率往往要比實現(xiàn)在用戶空間高許多。比如，httpd等服務。
·如果內(nèi)核和用戶空間都需要使用該服務，那么最好實現(xiàn)在內(nèi)核空間，比如
隨機數(shù)產(chǎn)生。
Linux安全相關(guān)的功能毫無疑問是在內(nèi)核中實現(xiàn)的，所以只有系統(tǒng)調(diào)用是安全
的，整個Linux系統(tǒng)的安全才有保障。
系統(tǒng)調(diào)用和普通的C函數(shù)調(diào)用不同，Linux中實現(xiàn)系統(tǒng)調(diào)用利用了0x86體系
結(jié)構(gòu)中的軟件中斷，軟件中斷和我們常說的中斷(硬件中斷)不同之處在于——它是
通過軟件指令觸發(fā)而并非外設，也就是說又編程人員出發(fā)的一種異常，具體的講
就是調(diào)用int Ox80匯編指令，這條匯編指令將產(chǎn)生向量為128的編程異常，即中斷
描述符表中的第128項，這一項中含有一個預設的內(nèi)核空間地址，它指向了系統(tǒng)
調(diào)用處理程序。之所以系統(tǒng)調(diào)用需要借助異常實現(xiàn)，是因為當用戶態(tài)的進程調(diào)用
一個系統(tǒng)調(diào)用時，CPU需要被切換到內(nèi)核態(tài)執(zhí)行內(nèi)核函數(shù)。所有的系統(tǒng)調(diào)用都會
統(tǒng)一的轉(zhuǎn)到這個地址，Linux一共有上百個系統(tǒng)調(diào)用都從這里進入內(nèi)核，Linux為
每個系統(tǒng)調(diào)用都進行了編號，同時在內(nèi)核中保存了一張系統(tǒng)調(diào)用表，該表中保存
了系統(tǒng)調(diào)用編號和其對應的服務例程，因此在系統(tǒng)調(diào)入陷入內(nèi)核前，需要把系統(tǒng)
調(diào)用號一并傳入內(nèi)核。在x86上，這個傳遞動作是通過在執(zhí)行intOx80前把調(diào)用號
裝入eax寄存器實現(xiàn)的。系統(tǒng)調(diào)用完成后，控制權(quán)被交回到發(fā)起調(diào)用的用戶進程。
42
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
系統(tǒng)調(diào)用必須用C語言實現(xiàn)。
Shell命令測試：
如圖4．1所示，系統(tǒng)調(diào)用是用戶使用的內(nèi)核提供的服務的一種接口，提供了用
戶與內(nèi)核進行交互操作的一種接口，Shell是系統(tǒng)的用戶界面，提供了用戶與內(nèi)核
進行交互操作的另一種接口。Shell是系統(tǒng)的命令解釋器，它解釋由用戶輸入的命
令并且把它們送到內(nèi)核。Shell有自己的編程語言用于對命令的編輯，它允許用戶
編寫由shell命令組成的程序。
所以在對系統(tǒng)調(diào)用進行測試的同時，還應該對Shell命令是否能保證系統(tǒng)的安
全功能進行測試。
4．3測試用例設計
在4．1節(jié)中我們已經(jīng)分析了UGO權(quán)限管理方式和ACL機制。UGO是最基本
的訪問控制管理方式，ACL是建立在UGO權(quán)限管理方式基礎上的可選的機制。我
們應該先對不開啟ACL機制時的UGO權(quán)限管理方式進行測試，然后在對ACL機
制進行測試，后者也就是測試這兩種安全機制都工作時是否滿足安全功能需求。
圖4-2 Linux訪問控制機制測試分類
Figure 4-2 Test classification for Linux Access Control
根據(jù)CC中安全功能組件FDU～CC．2．1和FDP—ACC．2．2，訪問控制安全測試
應該分為訪問控制權(quán)授予測試和訪問控制實施測試兩類。又因為UGO權(quán)限管理方
43
北京交通大學碩十學位論文
式在特殊權(quán)限位開啟和關(guān)閉時安全功能不同，所以將對UGO的測試分為開啟特殊
權(quán)限位測試和不開啟特殊權(quán)限位的測試。測試的劃分如圖4．2所示。
訪問控制操作的客體，即文件包括一般文件和目錄文件，如果沒有特別說明
之后提到文件都包括一般文件和目錄文件兩類。測試時也應該對這兩種文件分別
測試。因為目錄的讀操作和寫操作都需要執(zhí)行權(quán)限，所以在測試用戶對目錄的讀、
寫時，需要在測試用例中文件權(quán)限的基礎上對目錄文件的該類用戶額外授予執(zhí)行
權(quán)限。
4．3．1 UGO訪問控制機制的測試設計
為了保證將所有的安全功能都覆蓋到，應該先對該訪問方式的類型進行分類。
UGO將權(quán)限按用戶分類，用戶分為文件所有者、同組用戶、其他用戶三類，所以
必須保證每一類中至少有一個用戶，才能通過這類用戶的行為判定安全功能是否
實現(xiàn)。
對UGO訪問控制測機制試所需用戶的設計如表4．1所示。當一個文件的所有
者為Userl，所在的組為Groupl時，User2是這個文件的同組用戶，User3是這個
文件的其他用戶。這就保證了文件所有者、同組用戶、其他用戶三類非別有不同
的用戶，可以覆蓋所有的訪問控制情況。
表4-1 UGO測試用戶列表
Table 4．1 User list for UG0 test
編號用戶該用戶所在的組
1 Userl Groupl
2 User2 Groupl
3 User3 Group3
UGO權(quán)限中的特殊權(quán)限位SUID、SGID和Sticky開啟和關(guān)閉時，訪問控制功
能是不同的。接下來我們分別在在特殊權(quán)限位關(guān)閉和開啟情況下，對這兩種測試
進行測試數(shù)據(jù)準備和測試用例的描述。
4．3．1．1沒有開啟特殊權(quán)限位時的測試設計
訪問控制授予測試的文件準備比較簡單，只需要一個所以者為Userl，用戶組
為Groupl，權(quán)限為rwxrwxrwx的文件“Test_ugo_change”。訪問控制授予測試的
測試用例如表4．2所示。
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
表4．2 UGO訪問控制權(quán)授予測試用例
Table 4-2 Test cases of UG0 authorization
編號用戶文件操作預期結(jié)果
4 Usetl Test_ugo_change 修改文件權(quán)限、所有者、用戶組允許
5 User2 Test ugo_change 修改文件權(quán)限、所有者、用戶組拒絕
6 User3 Test_ugo_change 修改文件權(quán)限、所有者、用戶組拒絕
而訪問控制實施的用例設計較為復雜。如果將rwxiwxrwx的每一種組合窮舉
就將有2的9次方，即512種組合，一類用戶對每一種組合都進行讀、寫和執(zhí)行
測試的測試用例數(shù)就是512乘3，即1536個，三類用戶對這些文件的測試用例數(shù)
是4608個。這其中必然存在著冗余。因為必須對三類用戶的每種操作都進行測試，
所有只能從測試條件中文件的準備上來消除這些冗余。下面我們來分析怎樣組合
文件權(quán)限的。
UGO對每一類用戶提供了讀、寫和執(zhí)行這三種權(quán)限。因為我們無法假設一類
用戶的權(quán)限不會影響另一類用戶的訪問控制，所以在測試一類用戶的讀、寫或執(zhí)
行權(quán)限時，應該將其他類用戶的該項權(quán)限設為和此類用戶權(quán)限相反的權(quán)限，而其
他用戶的其他權(quán)限都關(guān)閉。就就保證了UGO對每一類的訪問控制的實施是獨立的，
是UGO訪問控制實施安全測試的一個方面。
同樣，我們不能假設每一類用戶的讀、寫和執(zhí)行權(quán)限是沒有影響的，所以在
測試某種權(quán)限時，應該將該類用戶的其他權(quán)限開啟或關(guān)閉，這是UGO訪問控制實
施安全測試的另一個方面。但這樣會照成部分文件權(quán)限的重復。例如要測試Userl
的讀權(quán)限是，文件對Userl權(quán)限的組合是IWX和1"-．；測試Userl的寫權(quán)限時，文
件對Userl的組合是rwx和．w．；測試用戶Userl的執(zhí)行權(quán)限時，文件對Userl的
組合是rwx和．w．，對每一類用戶的用例就有3個是重復的。于是我們可以將這些
重復用例中的rwx分為變?yōu)閞w．，．wx和l'-X三種組合。如果這三種組合可以保證
讀、寫和執(zhí)行權(quán)限之間不會想和影響。
這樣對每類用戶某種權(quán)限獨立的測試將分為兩種情況，分別是權(quán)限位為1即
允許訪問和為0即不允許訪問。
于是總的測試用例個數(shù)是2乘2乘3乘3，等于36種，比所有權(quán)限組合的測
試工作量大大降低。訪問控制執(zhí)行測試用例如表4．3所示，其中所有文件的所有
者都是Userl，用戶組都是Groupl。
45
北京交通大學碩士學位論文
表4-3 UGO訪問控制實施測試用例
Table 4．3 Test cases of UGO access control
編號用戶文件UGO權(quán)限操作預期結(jié)果
1 Userl Test__ugo_acccessl rw-?? 讀允許
2 Userl Test_ugo_access2 r-??- 讀允許
3 Userl Test_ugo——access3 -WX r--r-一讀拒絕
4 Userl Test_ugo_access4 ?r．-r-- 讀拒絕
5 Userl Test_ugo_access5 -wx?? 寫允許
6 Userl Test_ugo—．a(chǎn)ccess6 -W??· 寫允許
7 Userl Test_ugo_access7 r-x娟，--w- 寫拒絕
8 Userl Test_ugo_access8 ?-W-·-W一寫拒絕
9 Userl Test_ugo_access9 r-x?? 執(zhí)行允許
10 Userl Test_ugo_accessl0 ?X?-- 執(zhí)行允許
11 Userl Test ugo_accessll r、)lr?X—·X 執(zhí)行拒絕
12 Userl Test_ugo_accessl2 ?一X--X 執(zhí)行拒絕
13 User2 Test_ugo_accessl3 ?IW一? 讀允許
14 User2 Test_ugo_accessl4 ?r--? 讀允許
15 User2 Test_ugo_accessl5 r--一WX r·· 讀拒絕
16 User2 Test_ugo——accessl6 r．?-r-一讀拒絕
17 User2 Test_ugo_accessl7 ?-WX--一· 寫允許
18 User2 Test_ugo_accessl8 ?·W-? 寫允許
19 User2 Test_ugo_accessl9 -、Ⅳ一r-X娟r- 寫拒絕
20 USer2 Test_ugo_access20 -W-?一W一寫拒絕
21 User2 Test_．ugo——acccess21 ?卜X一執(zhí)行允許
22 User2 Test ugo_acccess22 ?一X? 執(zhí)行允許
23 User2 Test_ugo_acccess23 --X IW一一一X 執(zhí)行拒絕
24 User2 Test_ugo_acccess24 一-X?-·X 執(zhí)行拒絕
25 User3 Test ugo——acccess25 ??rW- 讀允許
26 User3 Test_ugo_acccess26 ??r-- 讀允許
27 User3 Test_ugo_acccess27 r--r---wx 讀拒絕
28 User3 Test ugo_acccess28 ro-r--? 讀拒絕
29 User3 Test_ugo—．a(chǎn)cccess29 ??-WX 寫允許
30 Uset3 Test_ugo_acccess30 ??一W- 寫允許
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
編號用戶文件UGO權(quán)限操作預期結(jié)果
31 User3 Test_ugo_acccess3 1 -Wo-W-1"-X 寫拒絕
32 User3 Test_ugo_acccess32 -：鼬一·：’瀚一? 寫拒絕
33 User3 Test_ugo_acccess33 ?--r-X 執(zhí)行允許
34 User3 Test_ugo_acccess34 ??一X 執(zhí)行允許
35 User3 Test ugo_acccess35 --X·-X r、^，· 執(zhí)行拒絕
36 User3 Test_ugo_acccess36 --X--X一執(zhí)行拒絕
4．3．1．2開啟特殊權(quán)限位
UGO中的SUID和SGID只對可執(zhí)行程序起作用，SUID的作用是二進制可執(zhí)
行程序?qū)Y源的訪問擁有該程序文件所有者的權(quán)限，SGID的作用是二進制可執(zhí)行
程序?qū)Y源的訪問擁有文件用戶組的權(quán)限。但SGID對程序文件的所有者不起作
用。Sticky只對文件夾作用，如果文件夾設置了Sticky，即使對文件夾有寫權(quán)限也
不能刪除該文件夾中所有者不是自己的文件或文件夾。
開啟權(quán)限位后對UGO訪問控制授予測試，要驗證這三個位對文件權(quán)限的授予
沒有影響。需要準備的文件如表4．4所示，其中所有文件的所有者是Userl，用戶
組為Groupl，權(quán)限為rwxrwxrwx。
表4_4開啟特殊權(quán)限位后UGO訪問控制權(quán)授予文件列表
Table 4-4 File list of UGO authorization test when SUID，SGID，Sticky Bit are turned On
編號文件特殊權(quán)限
37 Test sugid_st__changel SUlD
38 Test_sugid_stchange2 SGID
39 Test sugid_stchange3 Sticky
40 Test_sugid_st change4 SUID+SUID+sticky
測試用例如表4．5所示：
表4-5開啟特殊權(quán)限位后UGO訪問控制權(quán)授予測試用例
Table 4-5 Test eases of UGO authorization when SUID，SGID，Sticky Bit are turned on
編號用戶文件操作預期結(jié)果
Usetl 修改文件權(quán)限、所有者、用戶組允許
41
Test_sugid_st changel
User2
Test_sugid_st_change2 修改文件權(quán)限、所有者、用戶組拒絕42
Test_sugid_st_change3
User3 Test sugid——st__change4
修改文件權(quán)限、所有者、用戶組拒絕43
47
北京交通大學碩士學位論文
開啟SUID、SGID和Sticky位后的UGO訪問控制實施測試可以分為開啟SUID
或SGID后起作用和不起作用的兩類和開啟Sticky后起作用和不起作用的兩類，如
表4-6所示。對于那些特殊權(quán)限位不起作用的測試，可以復用表4．3中的用例，只
需要把表4—3中的文件的SUID、SGID和Sticky位開啟即可，測試預期結(jié)果不變。
對于起作用類的測試需要重新設計測試用例。
表4-6開啟特殊權(quán)限位后UGO訪問控制權(quán)實施測試分類
作用SUID或SGlD開啟Sticky開啟
讀讀
文件寫
寫文件
不起作用
執(zhí)行
讀
讀
目錄
寫目錄寫(除了刪除該目錄下的文件或目錄)
執(zhí)行執(zhí)行
起作用文件執(zhí)行目錄刪除該目錄下的文件或目錄
SUID開啟后，任何用戶執(zhí)行程序文件，該文件對資源的訪問權(quán)限都等于文件
所有者對資源的訪問權(quán)限。首先應該測試可執(zhí)行程序SUID沒有開啟時用戶通過執(zhí)
行該程序?qū)Y源的訪問依賴于該用戶對資源的訪問權(quán)限，開啟SUID后的測試應該
分為兩類：一類是其他用戶對資源有訪問權(quán)限，但資源所有者沒有訪問權(quán)限；一
類是其他用戶對資源沒有訪問權(quán)限，但資源所有者對資源有訪問權(quán)限。每一類又
要分別對讀、寫和執(zhí)行權(quán)限進行分別測試。SUID開啟后對文件執(zhí)行權(quán)限的測試的
文件準備如表4-7所示。其中所有文件的所有者是Userl，用戶組是Groupl。
表4．7開啟SUID后UGO訪問控制權(quán)實施測試文件列表
Table 4-7 File list for UGO access control test when SUlD is turned on
編號文件權(quán)限文件內(nèi)容
1 Test_suid_accessl r、vX?X —X Tsul(1'WX一一-)
2 Test_suid_access2 rwx?x-x 讀、寫、執(zhí)行Tsu2(?rwx·．)
3 Test——suid_access3 I'WX?X·X 讀、寫、執(zhí)行Tsu3(??l'WX)
4 Test——suid—．a(chǎn)ccess4 rws?x—x 讀Tsu4(r-?----)
5 Test_suid_access5 rws?x·X 讀Tsu5(?卜卜)
6 Test suid——access6 nVS?X ·X 寫Tsu6(-w一??)
7 Test_suid_access7 IWS?X·X 寫Tsu7(?-w一-w-)
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
編號文件權(quán)限文件內(nèi)容
8 Test——suid—．a(chǎn)ccess8 rws-—X一—X 執(zhí)行Tsu8(?X?一．)
9 Test——suid——access9 r、ⅣS--X一一X 執(zhí)行Tsu9(??X-x)
SUID權(quán)限位測試用例如表4．8所示：
表4．8開啟SUID后UGO訪問控制權(quán)實施測試用例
Table 4-8 Test cases of UGO access control when SUID is turned on
編號用戶文件操作預期結(jié)果
1 Userl Test suid——accessl 執(zhí)行允許
Test_suid_access2
2 Userl 執(zhí)行拒絕
Test_suid_access3
3 User2 Test_suid__access2 執(zhí)行允許
Test_suid_accessl
4 User2 執(zhí)行拒絕
Test——suid——access3
5 User3 Test——suid——access3 執(zhí)行允許
Test—．suid——accessl
6 User3 執(zhí)行拒絕
Test_suid——access2
7 Userl Test__suid_access4 執(zhí)行允許
8 Userl Test——suid——access5 執(zhí)行拒絕
9 User2 Test—．suid—．a(chǎn)ccess4 執(zhí)行允許
10 User2 Test suid——access5 執(zhí)行拒絕
11 User3 Test—．suid—．a(chǎn)ccess4 執(zhí)行允許
12 User3 Test_suid_access5 執(zhí)行拒絕
13 Userl Test_suid_access6 執(zhí)行允許
14 Userl Test．—．suid—，access7 執(zhí)行拒絕
15 User2 Test_suid_access6 執(zhí)行允許
16 User2 Test_suid_access7 執(zhí)行拒絕
17 User3 Test_suid_access6 執(zhí)行允許
18 User3 Test_suid——access7 執(zhí)行拒絕
19 Userl Test_suid_access8 執(zhí)行允許
20 Userl Test——suid——access9 執(zhí)行拒絕
21 User2 Test——suid——access8 執(zhí)行允許
49
北京交通大學碩十學位論文
編號用戶文件操作預期結(jié)果
22 User2 Test_suid——access9 執(zhí)行拒絕
24 User3 Test_suid_access8 執(zhí)行允許
25 User3 Test_suid——access9 執(zhí)行拒絕
對SGID的測試和SUID的測試類似。文件準備如表4-9所示。其中所以文件
的所有者為Userl，用戶組為Groupl。
表4-9開啟SGID后UGO訪問控制權(quán)實施測試文件準備
Table 4—9 File list for UGO access control test when SGlD is turned on
編號文件權(quán)限文件內(nèi)容
1 Test_sgid——accessl r、)lrX一-X-一X 讀、寫、執(zhí)行Tsgl(rwx?---)
2 Test_sgid_access2 r、vX—X一一X 讀、寫、執(zhí)行Ts92(-一rwx--)
3 Test_sgid_access3 r、ⅣX一-X--X 讀、寫、執(zhí)行Ts93(??l'WX)
4 Test_sgid_access4 r、ⅣX--S一-x 讀Ts94(．．·r．----)
5 Test_sgid——access5 r、VX--S—X 讀Ts95(f-?-r．．)
6 Test_sgid_access6 r、VX··S--X 寫Ts96(-一-w?-)
7 Test_sgid——access7 r、VX--S—·X 寫Ts驢(-w?--w一)
8 Test_sgid—．a(chǎn)ccess8 九ⅣX--$一-x 執(zhí)行Ts98(?一-x---)
9 Test_sgid_access9 r、ⅣX一-S—X 執(zhí)行Ts99(一x一一-X)
SGID權(quán)限位測試用例如表4．10所示。和SUID測試用例不同的是，文件所有
者執(zhí)行程序時程序?qū)Y源的權(quán)限仍然是程序文件所有者對資源的訪問權(quán)限，不是
程序文件的用戶組對資源的訪問權(quán)限。
表4．10開啟SGID后UGO訪問控制權(quán)實施測試川例
T抽le 4．10 Tbst cases of UGO access control when SGID is turned on
編號用戶文件操作預期結(jié)果
1 Userl Test_sgid_accessl 執(zhí)行允許
Test_sgid——access2
2 Userl 執(zhí)行拒絕
Test sgid_access3
3 User2 Test_sgid——access2 執(zhí)行允許
Test_sgid_accessl
4 Uset2 執(zhí)行拒絕
Test_sgid——access3
5 User3 Test_sgid——access3 執(zhí)行允許
50
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
Test_sgid——accessl
6 User3 執(zhí)行拒絕
Test_sgid_access2
7 Userl Test_sgid_access4 執(zhí)行拒絕
8 Userl Test_sgid_access5 執(zhí)行允許
9 User2 Test_sgid_access4 執(zhí)行允許
10 User2 Test_sgid_access5 執(zhí)行拒絕
11 User3 Test_sgid_access4 執(zhí)行允許
12 User3 Test_sgid_．a(chǎn)ccess5 執(zhí)行拒絕
13 Usetl Test_sgid_access6 執(zhí)行拒絕
14 Userl Test_s酉d_access7 執(zhí)行允許
15 Use比Test_sgid_access6 執(zhí)行允許
16 User2 Test_sgid——access7 執(zhí)行拒絕
17 User3 Test_sgid_access6 執(zhí)行允許
18 User3 Test_sgid_access7 執(zhí)行拒絕
19 Userl Test sgid_access8 執(zhí)行拒絕
20 Userl Test_sgid_access9 執(zhí)行允許
21 User2 Test_sgid_access8 執(zhí)行允許
22 User2 Test_sgid_access9 執(zhí)行拒絕
23 USer3 Test_sgid—．a(chǎn)ccess8 執(zhí)行允許?
24 User3 Test_sgid_access9 執(zhí)行拒絕
因為SUID的優(yōu)先權(quán)高于SGID，所以當SUID和SGID同時開啟時的測試文
件只需在SUID文件準備的基礎上開啟SGID，測試用例和SUID的測試用例相同。
Sticky位的作用是防止非文件所有者刪除文件。我們將在一個所有用戶都有
讀、寫、執(zhí)行權(quán)限和Sticky位開啟的文件夾下，測試三類用戶對其他用戶的文件
的刪除、重命名和移動操作。在測試之前我們先要建立一個目錄TestDir，所有者
為Userl，用戶組位Groupl，權(quán)限為rwxrwxrwt。測試用例如表4。11所示，表中的
文件都需要在TestDir目錄下的創(chuàng)建。
表4-11開啟sticky后UGO訪問控制權(quán)實施測試用例
Table 4-11 Test cases of UGO access control when Sticky is turned on
編號用戶文件所有者用戶組操作預期結(jié)果
1 Userl 1'est st del Userl Groupl 刪除、重命名或移動允許
2 User2 Test st del Userl Groupl 刪除、重命名或移動拒絕
51
北京交通大學碩十學位論文
3 User3 Test——st——del User 1 Groupl 刪除、重命名或移動拒絕
4 Userl Tbst st del User2 Group2 刪除、重命名或移動拒絕
5 User2 Tbst st del User2 Group2 刪除、重命名或移動允許
6 User3 Test——st——del User2 Group2 刪除、重命名或移動拒絕
7 Userl Test——st——del User3 Group3 刪除、重命名或移動拒絕
8 User2 Test——st——del User3 Group3 刪除、重命名或移動拒絕
9 User3 Test——st——del Usel 3 Group3 刪除、重命名或移動允許
4．3．2 ACL訪問控制機制的測試設計
在ACL機制中權(quán)限的分配是以單個用戶和單個用戶組為單位的。我們的測試
用例要檢查ACL機制對文件所有者、組用戶和其他用戶和用戶組能否指定的訪問
權(quán)限是否正確實施。為了不受ACL的影響我們將mask都設為rwx權(quán)限。ACL訪
問控制測試所需用戶的設計和UGO訪問控制機制的用戶設計相同。ACL訪問控制
權(quán)授予測試用例如表4．12所示。其中Test acl changel文件的所有者為Userl，用
戶組為Groupl，權(quán)限是rwxrwxrwx，ACL權(quán)限為用戶Userl、User2、User3用戶
有rwx權(quán)限，組Userl有rwx權(quán)限。
表4．12ACL訪問控制權(quán)授予測試用例
Table 4．12 Test cases ofACL authorization
編號片j戶文件操作預期結(jié)果
1 Userl Test——acl—．changel 修改權(quán)限、所有者、屬組允許
2 User2 Test——acl changel 修改權(quán)限、所有者、屬組拒絕
3 User3 Test——acl changel 修改權(quán)限、所有者、屬組拒絕
4 Userl Test—．a(chǎn)cl changel 修改權(quán)限、所有者、屬組允許
5 USer2 Test——acl——change l 修改權(quán)限、所有者、屬組拒絕
6 User3 Test——acl——changel 修改權(quán)限、所有者、屬組拒絕
ACL的訪問控制實施測試的測試內(nèi)容為當用戶權(quán)限、組權(quán)限和UGO權(quán)限不一
致時是否實施了ACL中的用戶權(quán)限，ACL中用戶的權(quán)限和用戶所在的用戶組權(quán)限
不一致時是否用戶權(quán)限優(yōu)先，以及用戶組權(quán)限對用戶權(quán)限的影響。ACL只對文件
所有者之外的用戶起作用。ACL訪問控制權(quán)實施測試用例如表4．13所示。其中所
有文件的所有者都為Userl，用戶組為Groupl。
52
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
表4．13ACL訪問控制權(quán)實施測試用例
Table 4-13 Test cases of ACL access control
編號用戶文件權(quán)限ACL 操作預期結(jié)果
1 Userl Test——acl——accessl rwx?? u：Userl：x 讀寫執(zhí)行允許
2 Userl Test——acl——access2 u：Userl：rwx 讀寫執(zhí)行拒絕
3 Use以Test——acl——access3 ?rwx? u：U∞眨：x 讀寫執(zhí)行拒絕
4 User2 Test——acl——access4 u：User2：rwx 讀寫執(zhí)行允許
5 User3 Test——acl——access5 ??I'VCX u：User3：x 讀寫執(zhí)行拒絕
6 User3 Test——acl—．a(chǎn)ccess6 u：User3：rwx 讀寫執(zhí)行允許
7 Userl Test——acl——access7 g：Groupl：rwx 讀寫執(zhí)行拒絕
8 Userl Test——acl——access8 撇? g：Groupl：x 讀寫執(zhí)行允許
9 User2 Test—．a(chǎn)cl——access9 g：Groupl：rwx 讀寫執(zhí)行允許
10 User2 Test—．a(chǎn)cl——accesslO N-r、ⅣX— g：Groupl：rwx 讀寫執(zhí)行允許
11 User3 Test—。acl——accessll g：Groupl：rwx 讀寫執(zhí)行拒絕
12 USer3 Test—。acl——accessl2 ??rVlⅨ g：Groupl：rwx 讀寫執(zhí)行允許
13 Userl Test——acl——accessl3 l"WX?? g：Group3：rwx 讀寫執(zhí)行允許
14 Userl Test—．a(chǎn)cl——accessl4 g：Group3：rwx 讀寫執(zhí)行拒絕
15 User2 Test——acl——accessl5 g：Group3：rwx 讀寫執(zhí)行拒絕
16 User2 Test——acl——accessl6 ?r、)l，X? g：Group3：rwx 讀寫執(zhí)行允許
17 User3 Test—．a(chǎn)cl—．a(chǎn)ccessl7 ?一r、ⅣX g：Group3：rwx 讀寫執(zhí)行允許
18 User3 Test——acl——accessl8 g：Group3：rwx 讀寫執(zhí)行允許
u：User2：rwx
19 User2 Test——acl——accessl9 讀寫執(zhí)行允許
g：Groupl：x
u：Uset2：x
20 User2 Test——acl——access20 讀寫執(zhí)行拒絕
g：Groupl：rwx
4．4 安全測試自動化工具的設計與實現(xiàn)
4．4．1總體設計
安全測試自動化工具是的設計思路和第三章的OSSEF測評框架的設計思路類
似。將測試用例用易理解、標準、通用的語言精確的描述，測試引擎通過測試數(shù)
據(jù)提取模塊讀取測試用例，測試用例到測試流轉(zhuǎn)化模塊和用例轉(zhuǎn)化規(guī)則將測試用
53
北京交通大學碩士學位論文
例變?yōu)榭梢詼y試流文件，再由測試執(zhí)行模塊執(zhí)行測試流并獲取測試結(jié)果。系統(tǒng)總
體設計如圖4．2所示。
我們將python語言作為自動化測評工具的實現(xiàn)語言。Python是一種簡單易學，
功能強大的編程語言，它注重的是如何解決問題而不是編程語言的語法和結(jié)構(gòu)。
Python簡潔的語法和對動態(tài)輸入的支持，再加上解釋性語言的本質(zhì)，使得它在大
多數(shù)平臺上的許多領域都是一個理想的語言。Python是使用XML文檔的理想語
．j一
亡】o
圖4．2 Linux訪問控制安全測試自動化工具總體設計
Figure 4-2 Design of the automated security test tool for Linux access control
下面我們將對測試用例的描述方式、測試數(shù)據(jù)提取模塊、測試用例到測試流
轉(zhuǎn)化模塊、測試流執(zhí)行模塊給出詳細設計方案。
4．4．2測試用例描述方式的設計
首先，測試用例主要包括三個方面的內(nèi)容，一是測試條件的生成，也就是測
試數(shù)據(jù)準備，二是測試步驟，三是測試的預期結(jié)果。其次，測試用例轉(zhuǎn)化成的測
試流應該是有序的，所以為了便于轉(zhuǎn)化，我們的測試用例也應該是有序的，即描
述順序應該和測試順序一致。下面我們以對UGO訪問控制方式的sticky位的部分
測試用例為例給出測試用例的描述方式設計：
　
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
Userl
<／Name>
<／Subject>
User2
<／Name>
User3
<／Name>
<／Subject>
TestDir
<／Name>
<／Object>
<／Condition>
Testl
<／Name>
<／Object>
<／Condition>
delete<／Operation>
move<／Operation>
<／Process>
<／Case>
<／Test>
<／XML>
測試用例可以寫在一個或多個文件中，　元素是測試用例文件的根目錄，
每個測試用例文件都只能有一個根目錄，即　。我們用元素代表一個
測試項，例如對sticky位的測試用例。no屬性表示測試項編號，編號不能重復，
以便Case有唯一的ID。元素必須嵌套在　中。一個測試用例文件可以
55
北京交通大學碩十學位論文
有多個。代表一個測試用例，no表示測試用例編號，元素必
須嵌套在元素中。表示測試條件，包括主客體的建立。
元素可以位于中之|j{『，表示在很多測試用例中都需要的
測試條件，也可以位于中之前，表示某個測試用例需要的測試
條件。和分別表示測試條件主體和客體，所以這些元素必須嵌套
在元素中。元素表示需要建立的主體或客體名稱，它必須嵌套
在或qb。中含有許多屬性信息，它表示主體時包含主體
類型、主體所屬的用戶組等信息，它表示客體時包含客體類型、所有者、屬組、
UGO權(quán)限、路徑等信息。元素表示測試過程，表示測試步驟。
需要嵌,A,元素中。dfl包含主體、主體類型、客體、
客體類型、預期結(jié)果等屬性，其內(nèi)容是主體對客體的操作類型。
我們的測試用例結(jié)構(gòu)非常靈活，可以根據(jù)需要進行擴充。擴充后只要修改相
應的用例轉(zhuǎn)化規(guī)則即可。例如，上面的用例中沒有涉及到設置文件或目錄的ACL
屬性，需要設置時我們可以在元素中添加acl屬性，如下所示。處理這個
屬性，我們只要在規(guī)則中加入相應的設置ACL屬性的規(guī)則語句和系統(tǒng)調(diào)用程序即
可。需要注意的是，對測試用例現(xiàn)有設計的擴充必測試用例的有序性。
Test2<／Name>
另一點需要注意的是，需要盡可能的將信息集中在中間的元素中，例如將主
客體的所有屬性都集中寫在元素中，原因我們將在下一節(jié)中解釋。
4．4．3測試數(shù)據(jù)提取模塊的設計與實現(xiàn)
測試數(shù)據(jù)提取模塊的作用是從XML語言描述的測試用例中逐條的提取信息，
目的是為了最終轉(zhuǎn)化為測試流。
為了方便把測試用例分類，其存儲目錄可能包含很多目錄，不同測試項的測
試用例放在不同的目錄中，所以測試數(shù)據(jù)提取模塊需要遞歸的訪問測試用例文件
存儲目錄，對每個XML文件進行處理，將生成的測試數(shù)據(jù)寫入測試數(shù)據(jù)文件中。
但是如果對執(zhí)行順序有要求測試用例需要寫在一個文件中。
在設計測試數(shù)據(jù)提取提取模塊之前我們要設計提取后的數(shù)據(jù)形式。首先，提
取出的信息必須要便于用用例轉(zhuǎn)化規(guī)則解釋為測試流，其次，必須保證和測試用
例的描述順序一致。下面是我們根據(jù)上一小節(jié)中的測試用例設計出的提取后的信
息。測試數(shù)據(jù)必須要包含的三方面信息是：一、何時進行規(guī)則轉(zhuǎn)化，二、轉(zhuǎn)化需
要的所有數(shù)據(jù)，三、轉(zhuǎn)化的類型。所以我們用“靜”開頭表示注釋，“％．"表示轉(zhuǎn)
56
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
化的類型標識，“&amp;amp;"表示開始進行轉(zhuǎn)化，測試信息的名稱和具體測試內(nèi)容之前沒
有標識符號。下面是以4．4．2節(jié)中的測試用例為例，給出了提取后的測試數(shù)據(jù)格式
設計：
％XML
撐stan
％XMLrest．
no Sticky_Bit_test
％XMLrestCondition．
％XMLTestConditionSubject-
％XMLTestConditionSubjectNametype
user
grp Userl
value Userl
&amp;amp;
％XMLTestConditionSubject·
％XMLTestConditionSubjectName·
type user
grp User2
value User2
&amp;amp;
％XMLTestConditionSubjectNametype
user
grp Userl
value User3
&amp;amp;
％XMLTestConditionObject·
％XMLTestConditionObjectName—
usrUserl
ugo 1777
type dir
grp Userl
value TestDir
&amp;amp;
％XMI,TestCase．
57
北京交通人學碩士學位論文
no 001
％XMLTestCaseCondition．
％XMLTestCaseConditionObject-
％XMLTestCaseConditionObjectName·
usr Userl
type file
grp Userl
path T色stDi“
value Testl
&amp;amp;
％XMLTestCaseProcess．
％XMLTestCaseProcessOperationobj
TestDir廠restl
objty file
sub Userl
subty usr
result allow
value delete
&amp;amp;
％XMLTestCaseProcessOperation—
obj TestDir廠restl
objty file
sub Userl
subty usr
result allow
value move
＆
fiend
可以看到有的轉(zhuǎn)化類型標識下面是沒有信息的，這些標識我們就不需要為其
編寫轉(zhuǎn)化規(guī)則。所以上一節(jié)中提到的將信息集中的原因為了方便編寫轉(zhuǎn)化規(guī)則。
對一個測試用例文件的數(shù)據(jù)提取流程如圖4．3所示。數(shù)據(jù)提取模塊一次讀入一
個元素的標簽(標簽頭或標簽尾)或元素內(nèi)容，以之前我們規(guī)定的格式向測試數(shù)
據(jù)文件寫入轉(zhuǎn)化類型標識、屬性和內(nèi)容。
58
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)④
-● ??? ? ???” ?～ ??．
廠～一?讀入元素頭———==?．·??二?一讀入元素尾?一一
讀入元素內(nèi)容
將元素名稱加在在字符串變量
strtag,尾，將”％strtag·“格式的轉(zhuǎn)
化類型標識寫入測試數(shù)據(jù)文件，
如果元素有屬性則將屬性名稱和
內(nèi)容也寫入測試數(shù)據(jù)文件
是
否
圖4-3測試用例文件的數(shù)據(jù)流提取流程
Figure 4-3 Process of the information draw-out from the file of test cases
python的XML支持XML-SIG、xmllib、xmlproc、SAX。xmllib等是將XML
解析為樹形結(jié)構(gòu)。我們選擇了SAX庫的原因是，SAX(SimpleAPI ofXML)是一
種面向流的技術(shù)，是一個XML文檔的順序處理器，正好符合我們測試信息和測試
用例的描述順序一致的要求。下面是用python語言編寫的測試數(shù)據(jù)提取模塊中處
理元素及其屬性主要的類和函數(shù)：
def FindTestFile(path)：
”’查找沒有處理的測試用例文件”’
class MakeTestInfo(handler．ContentHandler)
”’提取測試數(shù)據(jù)類"’
strtag=“％”
def startDocument(sel0：
”’文件處理之前進行的操作"’
def endDocument(self)：
”’文件處理之后進行的操作”’
def startElement(self,name，attrs)：
”’讀入元素頭后對元素的名稱、屬性的操作?
def endElement(self,name)：
59
北京交通大學碩士學位論文
?讀入元素尾后的操作”’
def characters(selCchrs)：
?讀入元素內(nèi)容后對內(nèi)容的操作?
4．4．4用例轉(zhuǎn)化規(guī)則的設計
用例轉(zhuǎn)化規(guī)則是提取出的測試信息和測試流的對應關(guān)系。我們?nèi)匀挥谩埃ィ?quot;
表示轉(zhuǎn)化類型標識，用“@”標識轉(zhuǎn)化過程中需要替換的變量，變量名稱應該和測
試用例中的屬性名稱一致?！埃骸睒俗R同一轉(zhuǎn)化類型的不同轉(zhuǎn)化規(guī)則，即根據(jù)不同的
屬性對轉(zhuǎn)化規(guī)則分類。例如，“：@type file"表示如果屬性type的值是file就使用
其下的規(guī)則直到遇到下一個不滿足的條件判斷或“％．"?！办o!"標識需要捕獲測試
結(jié)果和進行測試結(jié)果分析，此標識我們將在4．4．6中講述。下面是4．5．3節(jié)中測試
數(shù)據(jù)到測試流的轉(zhuǎn)化規(guī)則：
％XMU陀st．
#Test@no
％XMLTestCase．
#Case@no
％XMLTestConditionSubjectName-
：@type user
groupadd@grp
useradd@grp-g@value
％XMLTestCaseConditionObjectName-
：@type file
path=”TestDir”
path=path”@value”
SU@usr-c”>”$path
chgrp@grp
chmod@ugo$path
setfacl—m@u：Userl：rwx$path
：@type dir
pa=”@path@value”
su@usr—C”mkdir”$pass
chgrp@grp
chmod@ugo Spa
60
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
setfacl—m@acl Spa
％XMLTestCaseProcessOperation-
：@value delete
：@subty usr
靜!
SU@usr—c”rm-rf@obj”
@syscalltest／delete@obj
襻!@result
：@value move
：@subty usr
舞!
SU@usr-c”mv@obj@obi_mv”
@syscalltest／move@obi@obj mv
靜!@result
@syscalltest是系統(tǒng)調(diào)用系統(tǒng)調(diào)用測試程序的存儲路徑。由于對Linux系統(tǒng)調(diào)
用的測試python無法完成，所以需要在編寫規(guī)則的同時用C語言編寫完成并編譯
成可執(zhí)行程序，放在系統(tǒng)調(diào)用測試程序的的存儲路徑中。下面列出了chmod系統(tǒng)
調(diào)用測試程序。
銜nclude
#include ．
#include
_syscall2(int，chmod，const char*,path，mode_t，mode)
int main(int argc，char術(shù)argv[])
{
retum chmod(argv[1]，0777)；
}
雖然系統(tǒng)調(diào)用的過程比較復雜，但Linux系統(tǒng)的庫函數(shù)中提供幫助我們實現(xiàn)系
統(tǒng)調(diào)用的宏。_syscall2(int，chmod，const char*,path，mode_t，mode)是一個系統(tǒng)調(diào)用宏，
它展開以后是一段匯編代碼，通過其中的int Ox80中斷使程序從用戶態(tài)切換到系統(tǒng)
態(tài)，測試Linux底層的安全功能。C語言編寫的系統(tǒng)調(diào)用測試程序中我們通過return
將系統(tǒng)調(diào)用的返回值給main函數(shù)，這樣就可以在執(zhí)行這個二進制程序時捕獲到系
統(tǒng)調(diào)用的測試結(jié)果。
測試用例中的一個測試步驟并不只對應一條測試命令，例如對文件或目錄讀操
作進行測試時我們需要將對Shell中說有的可以對文件或目錄進行讀操作相關(guān)的命
61
北京交通大學碩+學位論文
令和系統(tǒng)調(diào)用中對文件進行讀操作的系統(tǒng)調(diào)用進行測試，只有當這次測試都通過
才表明這個測試用例通過測試。
4．4．5測試數(shù)據(jù)到測試流轉(zhuǎn)化模塊的設計與實現(xiàn)
測試數(shù)據(jù)到測試流轉(zhuǎn)化模塊的功能是根據(jù)讀取的測試數(shù)據(jù)去查找對應的轉(zhuǎn)化
規(guī)則，通過一系列的判斷、替換最后生成一個測試流文件。其工作過程如圖4．4
所示。
此模塊按順序每次讀入一個轉(zhuǎn)化類型標識，到轉(zhuǎn)化規(guī)則中查找是否有和此類
轉(zhuǎn)化類型標識名稱相同的規(guī)則，如果沒有就跳過測試數(shù)據(jù)中此轉(zhuǎn)化類型標識下面
的屬性或內(nèi)容，繼續(xù)讀下一個轉(zhuǎn)化類型標識。如果有相應的規(guī)則就讀入屬性和內(nèi)
容，并用這些屬性和內(nèi)容來判斷應該使用哪些規(guī)則，判斷的規(guī)則在上一節(jié)有所講
述。替換規(guī)則中的變量時，如果規(guī)則中的變量屬性和內(nèi)容中沒有就將其替換為空
或不使用這條規(guī)則。例如，如果客體的屬性中沒有ACL屬性，則不使用規(guī)則“setfacl
—m@u：Userl：rwx$path”。其工作過程如圖4．4所示。
下面是測試用例到測試流轉(zhuǎn)化模塊的主要變量和函數(shù)：
Testlnfo—Dic={ ’type’ ：’usr’，
’usr’ ：’Userl’，
’grp’ ：’Userl’，
’ugo’ ：’1777’
'value’ ：’Testl’
}
靜Testlnfo—Dic是從測試數(shù)據(jù)文件中讀出的屬性值和內(nèi)容值的字典
def Transform(testinfofile)：
”’測試數(shù)據(jù)到測試流轉(zhuǎn)化函數(shù)?
62
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
否
￡???????～I毫否一
否
是
圖“測試數(shù)據(jù)到測試流轉(zhuǎn)化流程
Figure 4-4 Process of transformation from test information to test flow
下面所列的是4．4．3節(jié)中的測試數(shù)據(jù)根據(jù)4．4．4中的用例轉(zhuǎn)化規(guī)則通過測試用
例到測試流轉(zhuǎn)化模塊轉(zhuǎn)化后的結(jié)果：
#start
#Test Sticky_Bit_test
groupadd Userl
useradd Userl—g Userl
groupadd User2
useradd User2-g User2
groupadd Userl
useradd User3一g Userl
pa=”TestDir”
SU Userl—c”mkdir”Spa
chgrp Userl
chmod 1777 Spa
北京交通大學碩士學位論文
撐Case 001
path=”TcstDir”
path=path”Testl”
SU Userl·C’’>”$path
chgrp Userl
舞!
su Userl—c”1T11一rf 1陀stDir廠I’estl”
／syscalltest／delete TestDir／Testl
#!allow
撐!
su Userl—c”mv TestDir廠restl TestDir爪stl mv”
／syscalltest／move TestDir／Testl TestDir／Testl_mv
舞!allow
#end
4．4．6測試流執(zhí)行模塊的設計與實現(xiàn)
轉(zhuǎn)化后的測試流可以說是一個Linux命令的集合，類似一個Shell腳本，之所
以稱之為測試流而不是測試腳本是因為我們不能直接用其進行測試，因為直接執(zhí)
行不能夠捕獲測試結(jié)果，從而不能進行測試結(jié)果的分析。我們設計了一個測試流
執(zhí)行模塊來負責執(zhí)行這些命令。
我們將測試命令分為兩類：測試步驟和非測試步驟。以上一節(jié)中的測試流為
例，只有“撐!”標識之間的部分是測試步驟，其他的否是非測試步驟，測試條件的
建立都是非測試步驟。只有在執(zhí)行測試步驟時需要捕獲測試結(jié)果，執(zhí)行非測試步
驟則不需要，所以在測試步驟前標識“撐!”是為了執(zhí)行時區(qū)分這兩種測試步驟。測
試步驟的結(jié)束標識中還包含了測試的預期結(jié)果，例如“#!allow"標識預期測試結(jié)
果為“允許”，這樣設計方便于進行測試結(jié)果的比對。測試流執(zhí)行模塊將逐行執(zhí)行
測試命令，當讀到“#!allow"時進行測試結(jié)果判斷。測試流執(zhí)行模塊將測試項編
號、測試用例編號、預期結(jié)果、測試結(jié)果和測試是否通過的結(jié)論都將寫入測試報
告中。測試用例執(zhí)行模塊的工作過程如圖4．5所示。
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
??? ??◆●
?讀入注釋撐??一讀入測試步驟標識撐!
其他
◆
是否d≥?一由
圖4-5測試流執(zhí)行過程
Figure 4-5 Execution process of the test flows
下面是測試執(zhí)行模塊的主要函數(shù)：
def not_operation_commond(cmd)：
”’讀取注釋或非測試步驟命令并執(zhí)行將測試項和用例編號寫入測試報告，，，
def operation_commond(cmd)：
”’執(zhí)行測試步驟，并將測試結(jié)果寫入測試報告，，，
defjudge O：
”’判斷測試結(jié)果是否正確?
4．5 安全測試自動化工具的運行
在安全測試自動化工具開發(fā)完成之后，我們要對Linux系統(tǒng)進行測試。我們選
擇的測試對象是fedora 8 Linux系統(tǒng)。測試之前我們將手動編寫好所有的測試用例
和用例轉(zhuǎn)化，圖4-6是Linux訪問控制安全測試用例的目錄結(jié)構(gòu)。
北京交通大學碩十學位論文
審囪testdir
審囪ACL
o access．xml
!?j Change．xm 一
審囪UGO
審囪without—sugid_sticky
l!access．xml
j change．xml
審囪with sugid_sticlcy
7 access_with_sgid．xml
j access_with_sticky．xml
j access_with_suid．xml
；1 change．xml
2項文件夾
2項文件夾
。字節(jié)xML document
0字節(jié)xML document
2項文件夾
2項文件夾
0字節(jié)XML document
0字節(jié)XML document
4項文件夾
0字節(jié)XML document
0字節(jié)XML document
0字節(jié)XML document
o亭昂XML document
圖4-6 Linux訪問控制測試用例目錄結(jié)構(gòu)
Figure 4-6 Directory structure for test cases of Linux access control
Linux訪問控制安全測試自動化工具運行過程的界面如圖4．7所示： 緩茲渤滋緩隔綴綴綴緩編綴黝薹程狻綴筏纜緩緩綴黼溺戮滋緩綴緩貔瀧=澎。乏弱
文件(￡) 編輯(丘) 查看(芏)終湍(工) 標簽(旦) 幫助(旦)
[rootOIocaIhost st】#python AJtoTestingT001．PY／tnp／testdl r／trrd／tr艄f—ruI∞
№ke test info?
Transform．．．
Testing?PIease帕i t
Co叩leteII
See TestReport．txt
[rootOIocaIhost st】#python AJtoTestIngT001．PY／tnp／testdi r／tnd／transf—ruI鷗
陀ke tost info?
Transform．．．
Testing?Please怕i t
CorrpleteII!
See TestReport2．txt ．
[root010ca lhc騭t st】#
圖4-7工具的運行界面
Figure 4—7 Running interface of the tool
python是編譯python程序的編譯器，AutoTestingT001．PY是安全測試自動化工
具程序，它的第一個參數(shù)是測試用例的存儲目錄，第二個參數(shù)是測試用例轉(zhuǎn)化規(guī)
則文件的位置。運行安全測試自動化工具后在當前目錄生成了測試報告
TestReport．txt，當我們再次運行工具后，上一次生成的測試報告文件沒有被覆蓋，
而是生成了測試報告TestReport2．txt。下面是測試報告部分的內(nèi)容：
Linux訪問控制安全測試自動化工具的設計與實現(xiàn)
#Test Report 2008—·4—-18 21：59：23
#start
#Test Stick)邙iLtest
#Case 001
expect：allow result：allow pass
#Case 002
expect：deny result：deny pass
#Case 003
expect：deny result：deny pass
#Case 004
expect：deny result：deny pass
#Case 005
expect：allow result：allow pass
#end
#All of the cases pass
測試報告對每一個測試用例是否測試通過給出了判斷，最后給出了所以測試
用例是否通過的判斷。在測試用例眾多和在多次反復的測試中，測試自動化工具
的優(yōu)勢就能明顯體現(xiàn)出來。手動測試這些用例大約需要近半天的時間，如果要多
次執(zhí)行測試需要的時間就更多，是十分枯燥的工作。用我們的測試自動化工具完
成這樣的測試一次只需要不到一分鐘的時間。
由上述測試報告可知，fedora8通過了所有訪問控制安全功能測試用例，所以
fedora8的訪問控制安全功能達到了安全要求。
4．6 安全測試工具的討論
工具的優(yōu)點：
·此工具具有很好的擴展性，只需要進行安全功能分析，安全需求分析，測
試用例設計，用例轉(zhuǎn)變規(guī)則編制，就可以標識與鑒別、安全審計等安全功
能實現(xiàn)自動化測試。當操作系統(tǒng)發(fā)生改變后，只需要修改用例轉(zhuǎn)換規(guī)則，
而測試用例是可以復用的；
·測試用例設計也是測試的一個重點，我們給出了Linux訪問控制安全測試
的完整測試用例設計，并對測試思路進行了闡述。
67
北京交通人學碩士學位論文
工具的缺點：
· 測試規(guī)則中有重復的部分，應該對測試規(guī)則的設計進行優(yōu)化；
· 測試用例的測試條件建立中部分測試數(shù)據(jù)可以提取出來，放在數(shù)據(jù)文件
中，這樣就減輕了為相同類型測試條件的建立而帶來的測試用例丌銷；
· 測試用例的編寫、管理不方便。應該設計一個圖形界面的測試用例管理工
具。
4．7 小結(jié)
本章就描述了Linux訪問控制安全測試設計和一個Linux系統(tǒng)的訪問控制安全
測試自動化工具的設計與實現(xiàn)，并對該工具進行了討論。雖然這只是操作系統(tǒng)安
全測評自動化之路中的-d,步，但也將是非常有意義的嘗試。
結(jié)束語
5 結(jié)束語
本章首先對本論文所做的主要工作做了總結(jié)和回顧，之后對未來進一步的研
究工作做了展望。
5．1 工作總結(jié)
操作系統(tǒng)是整個信息系統(tǒng)安全的基礎，如果不經(jīng)過安全測評操作系統(tǒng)其安全
性就得不到保障。而且隨著我國操作系統(tǒng)研究的不斷發(fā)展，設計有效的測評自動
化工具已成為迫切的要求。
對安全測評方法的分析是安全測評自動化的基礎。而安全測評標準是安全操
作系統(tǒng)測評方法的體現(xiàn)，安全測評標準的發(fā)展歷程也就是安全測評方法發(fā)展的過
程。于是本文概述了現(xiàn)有的安全測評標準。由于我們在安全測評領域和發(fā)達國家
還有一定差距，所以國內(nèi)很多操作系統(tǒng)測評工作都是以國外的測評標準為依據(jù)的，
例如現(xiàn)階段最為完善的CC標準。遺憾的是很多對CC標準的使用和理解都是不全
面、不完善的。于是本文對整個CC安全測評體系做了詳細的分析，總結(jié)了CC安
全體系測評方法的基本要領和測評流程。
接下來我們文分析了國內(nèi)現(xiàn)有的兩種典型的安全測評自動化系統(tǒng)的設計方
法，對其優(yōu)缺點做了總結(jié)，在吸取這些系統(tǒng)的優(yōu)點和融合了軟件測試自動化方法
的基礎上給出了改進后的安全測評自動化框架設計，并分析了技術(shù)難點和給出了
解決方案。
由于操作系統(tǒng)測評自動化系統(tǒng)是一個龐大的系統(tǒng)，其工作量不亞于操作系統(tǒng)
開發(fā)的工作量，實現(xiàn)起來需要相當大的人力物力和時間。所以本文只能在操作系
統(tǒng)安全測評的眾多工作中找一個切入點來對整個操作系統(tǒng)的安全測評自動化的實
現(xiàn)進行探索和討論。訪問控制安全是操作系統(tǒng)安全的一個非常重要組成部分，同
時國內(nèi)自主研發(fā)的操作系統(tǒng)大多使用的開源的Linux系統(tǒng)內(nèi)核，開發(fā)出系統(tǒng)的體系
結(jié)構(gòu)相同，對Linux系統(tǒng)測試自動化方法的研究和工具的實現(xiàn)有很強通用性和實用
價值。所以本文以Linux系統(tǒng)訪問控制安全為切入點，對操作系統(tǒng)安全測評自動化
進行了探索，并設計和實現(xiàn)了Linux訪問控制安全測試自動化工具。在人工編制用
例轉(zhuǎn)化規(guī)則的基礎上，該工具可以實現(xiàn)自動執(zhí)行XML語言描述的特定格式的訪問
控制安全測試用例，測試結(jié)果判斷和給出測試報告。并給出了對工具優(yōu)缺點的討
論。
北京交通大學碩士學位論文
5．2研究展望
本文對操作系統(tǒng)安全測評方法和流程作了較為深入的研究，對操作系統(tǒng)安全
測試自動化進行的研究也取得了一定的實踐成果，但將來還有很多工作需要進一
步的深入和完善。
在操作系統(tǒng)安全測評方法方面，應該對CC安全測評體系進行更深入的分析，
尤其是對安全保證的評估做進一步的研究。
在操作系統(tǒng)安全測試研究方面，未來的工作可以在以下方面展開：
(1)分析操作系統(tǒng)各個安全機制的安全功能；
(2)對每種安全機制進行測試用例設計；
(3)分析測試用例設計的合理性、覆蓋率。
在安全測試自動化的研究方面，本文工作的基礎上，還應該對Linux安全測試
自動化工具的以下方面進行改進：
(1)測試數(shù)據(jù)從測試用例文件中分離：當測試用例的測試條件建立中存在
大量相同類型的測試條件時，部分測試數(shù)據(jù)可以提取出來，放在數(shù)據(jù)
文件中，以較小測試用例的長度；
(2)為工具添加測試用例管理器：即實現(xiàn)一個測試用例的圖形化管理工具，
功能包括用例的添加、刪除、修改和查詢；
(3)工具中重復性規(guī)則的消除：工具中現(xiàn)有的用例轉(zhuǎn)化規(guī)則存在冗余，應
該對冗余進行分析和消除；
(4)測試自動化程度的提高：通過更加抽象的測試用例描述方法，自動生
成XML測試用例文件。
參考文獻
參考文獻
【1】CC，“Common Criteria for Information Technology Security Evaluation”，September 2007．
【2】2 CEM，“Common Methodology for Information Technology Security Evaluation”，September
2007．
【3]CCRA，‘'Arrangement on the Recognition of Common Criteda Certificates In the field of
Information Technology Security'’，May 2000．
【4】崔永禎，“安全操作系統(tǒng)測評方法研究”，中國科學院軟件研究所碩士學位論文，2004年。
【5】陳軼佳，周安民，方勇，王煒，曹軍，“信息安全產(chǎn)品測評系統(tǒng)研究與實現(xiàn)”，《計算機應
用研究》，2005年。
【6】牛妍萍，呂述望，“Linux文件訪問控制及其自動化測試”， 《信息安全與通信保密》，
2006年9月。
【7】陸幼驪，張紅旗，“操作系統(tǒng)安全測評系統(tǒng)設計”， 《信息安全與通信保密》，2005年8
月。
【8】石文昌， “安全操作系統(tǒng)研究的發(fā)展”， ‘計算機科學》，2002年。
【9】Evan Martin，"Testing and Analysis of Access Control Policies”，29th International ConVince
on Software Engineering，2007．
【10】Evan Martin，"Automated Test Generation for Access Control Policies”，Proceedings of the
29th International Conference on Software Engineering Workshops，2006．
【11】金怡，蔡勉，“基于CC標準的安全操作系統(tǒng)測評系統(tǒng)研究”，《信息安全與通信保密》，
2007年5月。
【12】常偉華，蔡勉，王亞軍，“基于驅(qū)動表機制的操作系統(tǒng)等級測評系統(tǒng)”， 《信息安全與
通信保密》，2007年6月。
【13】Songtao Zhang，Thomas Dean，Scott Knight，“A Lightweight Approach to State Based Security
Testing”，IBM Centre for Advanced Studies Conference，Article No．28，2006．
【14】Wissam Mallouli，Jean-Marie Orset，Ana CavaUi，“A Formal Approach for Testing Security
Rules”，SACMAT’07，June 20·22，2007．
【15】魏丕會，卿斯?jié)h，黃建，“安全操作系統(tǒng)等級評測系統(tǒng)”，《計算機工程》第22期，2003
年12月。
【16】Gary McGraw，Bruce Potter，“Software Security Testing'’，IEEE Security and Privacy，v01．2，
No．5，PP．81·85，September-October 2004．
【17】Martin R．Stytz，James A．Whittaker，“Software Protection：Security's Last Stand?”，IEEE
Security and Privacy,v01．01，No．1，PP．95．98，January—February 2003．
【18】Clifton L Smith，“The Security Systems Research and Testing Laboratory at Edith Cowan
University'’，Security Technology，2005．CCST’05．39th Annual 2005 International Carnahan
Conference．2005．
【19】VlRGlL D．GLIGOR，C．S．CHANDERSEKAR AN，WEN—DER JIANG，ABHAI JOHRI，
GARY L LUCKENBAUGH，L．EDWARD REICH，‘‘A New Securty Testing Method and Its
Application to the Secure Xenix Kemel”，1EEE TRANSACTIONS ON SOFIWARE
ENGINEERING，V01．SE．13，No．2，F(xiàn)ebruary 1987．
71
北京交通大學碩士學位論文
【20】GB 17859．1999，“中華人民共和國國家標準計算機信息系統(tǒng)安全保護等級劃分準則”，
國家質(zhì)量技術(shù)監(jiān)督局，1999年9月。
【211倪繼利， “Linux安全體系分析與編程”，2007年11月，電子J：業(yè)出版社。
【22】Claudia Salzberg Rodriguez，Gordon Fischer，Steven Smolski，陳莉君，賀炎，劉霞林，“Linux
內(nèi)核編程”，2006年7月，機械T業(yè)出版社。
【23】“Linux的安全操作系統(tǒng)測試方法研究”， 《鐵路計算機應用》，V01．15 No．4，2006。
【24】王兆俊， “Linux桌面操作系統(tǒng)安全性測試研究”，北京科技大學碩士學位論文，2006。
【25】高常波，“CC工具箱系統(tǒng)開發(fā)”，四川大學碩士學位論文，2004。
【26】左曉棟， “信息安全產(chǎn)品與系統(tǒng)的測評與標準研究”，中國科學院研究生院碩士學位論
文，2002。
【27]陳馳，馮登國，張敏，徐震，“信息安全產(chǎn)品測評平臺的設計與實現(xiàn)”，計算機：．I：程，
V01．33 No．8，2007年4月。
【28】陳軼佳，周安民，方勇，王煒，曹軍，“信息安全產(chǎn)品測評系統(tǒng)研究與實現(xiàn)”，計算機應
用研究，2005年。
【29】王春元，楊善林，周永務，“信息安全等級測評系統(tǒng)設計”，計算機工程與設計，V01．27
No．23，2006年12月。
[30】郝曉玲，胡克瑾，董歡歡，連曉海，邢蕙，“信息產(chǎn)品安全測評工具箱的研究與開發(fā)”，
計算機工程與應用，2004年6月。
【31】簡DJjPython教程，http：／／www．woodpecker．org．cn：9081／doc／abyteofpython cn／chinese／
【32】Documents about processing XMLwith Python，http：／／pyxml．sourceforge．net／topics／docs．html
作者簡歷
作者簡歷
陳晨，女，1983年6月28日出生，籍貫云南，碩士研究生?，F(xiàn)就讀于北京交通大學計算
機與信息技術(shù)學院計算機軟件與理論專業(yè)，主要從事操作系統(tǒng)安全測評和測試方面的研究。
位
教育經(jīng)歷：
2006年9月一至今：北京交通大學攻讀工學碩士學位
2001年9月一2005年7月：畢業(yè)于北京林業(yè)大學計算機科學與技術(shù)專業(yè)獲工學學士學
研究工作：
2007年7月—2008年5月，參與國家973項目“信息與網(wǎng)絡安全體系結(jié)構(gòu)研究”(項目
編號G1999035801)之子課題“操作系統(tǒng)安全評測平臺的研究”及北京交通大學?？萍蓟稹鞍?
全操作系統(tǒng)測評自動化研究”課題的研究。
73
操作系統(tǒng)安全測評及安全測試自動化的研究
作者： 陳晨
學位授予單位： 北京交通大學
相似文獻(10條)
1.會議論文常偉華.蔡勉.賈佳安全操作系統(tǒng)測評系統(tǒng)的研究與實現(xiàn) 2007
本文結(jié)合了GB/T18336-2001標準,設計了一個基于Linunx的安全操作系統(tǒng)的自動測評系統(tǒng)。該系統(tǒng)基于數(shù)據(jù)驅(qū)動的自動化測評框架而構(gòu)建,核心引擎
通過驅(qū)動表機制生成測試套件,套件集成了所需的測試組件,在操作系統(tǒng)環(huán)境中自動完成安全測試,并按照評估流程生成評估報告。
2.會議論文李梅娟.蔡勉.常偉華.賈佳操作系統(tǒng)安全等級測評技術(shù)研究 2006
息產(chǎn)品安全測評是信息安全保障體系建設的重要部分.在闡述信息安全測評依據(jù)的基礎上,給出一個操作系統(tǒng)安全保護等級測評系統(tǒng)的設計方案,該系
統(tǒng)能夠半自動地完成操作系統(tǒng)安全保護等級測評.最后給出系統(tǒng)的測評流程.
3.學位論文常偉華 安全操作系統(tǒng)數(shù)據(jù)完整性與標記功能測評研究與實現(xiàn) 2008
本文闡述了安全操作系統(tǒng)測評的研究背景、意義和發(fā)展現(xiàn)狀,介紹了計算機操作系統(tǒng)安全標準、安全操作系統(tǒng)的基本概念、安全測評方法,并描述了
測評系統(tǒng)的整體架構(gòu)、模塊的設計思路和安全測評模型的建立流程；提出了安全操作系統(tǒng)中的數(shù)據(jù)完整性和標記強制訪問控制安全功能測試方法,設計實
現(xiàn)了測試工具,并對上述兩項安全功能進行了測試和分析。
本文所作的主要工作如下：
1.對測評系統(tǒng)進行了架構(gòu)設計和模塊設計,在安全操作系統(tǒng)開發(fā)模型的基礎上建立了安全測評模型,系統(tǒng)測評按功能分為：單元測試、集成測試和系
統(tǒng)測試；設計了驅(qū)動系統(tǒng)運行的數(shù)據(jù)處理模塊運行機制和驅(qū)動表機制。
2.分析了操作系統(tǒng)數(shù)據(jù)完整性安全功能要求,抽象出了需要測評的安全指標,給出了它們的測試方法,主要利用Shell編程對系統(tǒng)數(shù)據(jù)完整性安全功能
所涉及的安全要素進行測試,設計并實現(xiàn)了測試工具,在Fedora Core 5操作系統(tǒng)上對數(shù)據(jù)完整性安全功能進行了測試和分析,并給出相應的測試結(jié)果和報
告。
3.詳細分析了操作系統(tǒng)標記強制訪問控制安全功能要求,抽象出了需要測評的安全指標,并給出了它們的測試方法,利用Shell編程對系統(tǒng)的標記強制
訪問控制安全功能所涉及的安全要素進行測評,設計并實現(xiàn)了測試工具,在FedoraCore 5操作系統(tǒng)上對標記強制訪問控制安全功能進行了測試和分析,并給
出了相應的測試結(jié)果和報告。
4.期刊論文常偉華.蔡勉.王亞軍.CHANG Weihua.CAI Mian.WANG Yajun 基于驅(qū)動表機制的操作系統(tǒng)等級測評系統(tǒng)
-信息安全與通信保密2007,""(6)
操作系統(tǒng)安全是計算機信息安全的基礎,如何對操作系統(tǒng)的安全等級進行測評已成為一個重要的課題.論文依據(jù)GB/T18336-2001標準,設計了一個基于
Linux的操作系統(tǒng)的等級測評系統(tǒng).該系統(tǒng)通過驅(qū)動表機制驅(qū)動測評系統(tǒng)各組件運行,生成測試套件.測試套件集成了測試所需的測試組件,并可在操作系統(tǒng)
環(huán)境中自動完成安全測評,按照評估流程生成評估報告.
5.學位論文陸幼驪 安全操作系統(tǒng)測評工具箱的設計與實現(xiàn) 2005
安全操作系統(tǒng)測評技術(shù)研究是目前國內(nèi)較新的課題，尚沒有系統(tǒng)而完整的研究文獻。手工測評仍然是當前主要的測評手段，國內(nèi)缺乏自主研發(fā)的自
動化測評工具，隨著我國安全操作系統(tǒng)研究的不斷發(fā)展，設計有效的自動化測評工具己成為迫切的要求。
本文在安全操作系統(tǒng)、安全測評理論的基礎上，總結(jié)了主流測評技術(shù)，設計了一個基于Unix/linux的安全操作系統(tǒng)測評工具箱，該工具箱基于數(shù)據(jù)
驅(qū)動的自動化測評框架而構(gòu)建，核心引擎通過驅(qū)動表機制生成測試套件，套件集成了所需的測試組件，在操作系統(tǒng)環(huán)境中自動完成安全測試，并按照評
估流程生成評估結(jié)果。
測評的執(zhí)行過程分為單元級測試、集成級測試和系統(tǒng)級測試三個部分。單元級測試針對操作系統(tǒng)的各個功能單元(用戶命令、系統(tǒng)調(diào)用)進行安全機
制的檢查。集成級測試的對象是文件、進程、網(wǎng)絡、IPC等子系統(tǒng)，并且各子系統(tǒng)的測試組件在運行過程中提供驗證記錄，以完成對安全審計機制的測試
。系統(tǒng)級測試利用成熟的測試工具對系統(tǒng)性能進行驗證。此外，在安全測評之前先要進行預測試，預測試完成測試環(huán)境的驗證，以確保測試的順利進行
，測試對象是各個系統(tǒng)管理命令。
本文主要作出兩個貢獻：一是自動化測評驅(qū)動框架的設計，二是多級安全測試模型的設計。
6.期刊論文中嘉華誠公司 如何提高WinNT/2000的安全性--內(nèi)核加固實現(xiàn)一個真正強壯的操作系統(tǒng) -信息安全與通
信保密2005,""(3)
Windows 2000支持多處理器系統(tǒng)、安全性文件系統(tǒng)(例如目錄的讀寫限制),從Windows NT 3.51開始就已經(jīng)支持C2級的安全測評,是一個真正的32位操
作系統(tǒng),其核心不包含16位代碼(16位代碼僅存在于支持16位應用程序的代碼中)、規(guī)定16位代碼運行在其獨立的地址空間內(nèi)、系統(tǒng)是完全可重入的、規(guī)定
共享的內(nèi)存,只對于有相同共享內(nèi)存區(qū)域的進程是可見的(在Win 32 API中稱為"文件映射對象").以上這些特點構(gòu)成了一個強大的Windows 2000系統(tǒng).
7.學位論文金怡 安全操作系統(tǒng)自主訪問控制與滲透測試 2007
本文主要研究了安全操作系統(tǒng)的自主訪問控制和滲透測試的測評方法及其實現(xiàn)。首先介紹了操作系統(tǒng)測評的研究背景、國內(nèi)外發(fā)展現(xiàn)狀，闡述了國
內(nèi)外安全操作系統(tǒng)評測準則、安全操作系統(tǒng)的原理及安全功能和安全保證的測評方法。根據(jù)《計算機信息系統(tǒng)安全等級保護操作系統(tǒng)技術(shù)要求》(以下簡
稱《技術(shù)要求》)，給出了自主訪問控制功能和滲透測試的測評。
本文所做的工作主要如下：
1．分析和研究了《技術(shù)要求》，討論了自主訪問控制和滲透測試的基本原理，分析了滲透測試與系統(tǒng)抗攻擊能力的關(guān)系、滲透測試的五個階段以及
滲透測試的局限性等。
2．根據(jù)《技術(shù)要求》，給出了自主訪問控制測試準則、測試方法和測試工具，并在Fedora core 5系統(tǒng)上對自主訪問控制進行了測試和分析。
3．根據(jù)《技術(shù)要求》，給出滲透測試的總體方案和基本測試模型。提出了針對四種系統(tǒng)漏洞檢測模型的測試子方案。
8.期刊論文鄭森泉 供電企業(yè)信息網(wǎng)絡安全策略 -電力信息化2006,4(9)
0 引言
調(diào)查顯示,在Internet時代和廣域網(wǎng)條件下,信息網(wǎng)絡安全事件的發(fā)生也呈現(xiàn)飛速增長的趨勢.近幾年來,數(shù)據(jù)信息的安全、信息網(wǎng)絡的安全已經(jīng)成為
CIO(企業(yè)信息主管)最為關(guān)注的問題之一,同時CSO(首席安全主管)在企業(yè)中的地位愈加重要.遺憾的是,隨著IT技術(shù)發(fā)展的日新月異,大部分供電企業(yè)由于
在信息方面技術(shù)的儲備不夠,使企業(yè)信息化架構(gòu)策略模式陳舊,信息網(wǎng)絡規(guī)劃和設計也不全面,更談不上對系統(tǒng)安全的全面考慮.有的企業(yè)僅僅把目光投向
操作系統(tǒng)或者局域網(wǎng)絡的安全,認為只要預防病毒和黑客等外部侵襲就可以高枕無憂了,實際上,真正的數(shù)據(jù)安全威脅有時也來自企業(yè)局域網(wǎng)內(nèi)部.中國國
家信息安全測評認證中心的調(diào)查結(jié)果顯示,信息安全問題大部分情況下都是由內(nèi)部人員所為,存有大量敏感機密的數(shù)據(jù),對內(nèi)部毫不設防的計算機用戶才是
數(shù)據(jù)泄露的根源.
9.期刊論文許友.陳性元.唐慧林.高沛霖.XU YOU.CHEN XINGYUAN.TANG HUILIN.GAO PEILIN 基于標準的系統(tǒng)安全
測試指標體系的研究-微計算機信息2007,23(3)
本文從操作系統(tǒng)的安全功能出發(fā),結(jié)合CC標準的測評原理,按照威脅、安全目的、系統(tǒng)安全功能組件和具體指標的順序,提出一套系統(tǒng)安全測試的全面
的指標體系,該指標可根據(jù)需要運用層次分析法進行定性或定量的風險評估.
10.學位論文崔永禎 安全操作系統(tǒng)測評方法研究 2004
高等級安全操作系統(tǒng)測評方法研究是較新的研究課題,尚沒有系統(tǒng)而完整的研究文獻.隨著中國高等級安全操作系統(tǒng)研究與實踐的不斷發(fā)展,制定全面
有效的測評框架,對操作系統(tǒng)設計和實現(xiàn)等進行測評成為推動安全操作系統(tǒng)研究發(fā)展的迫切要求."安全操作系統(tǒng)測評研究"課題是"B2級安全操作系統(tǒng)研發(fā)
"課題的后續(xù)課題,其目標是建立一套適用于高安全等級操作系統(tǒng)的測評框架和方法,重點是測試范圍分析、基本功能測試、抗?jié)B透測試以及隱通道分析的
測試研究,并在此理論基礎上逐步實現(xiàn)完整有效的導航測評工具和自動化測評工具.該文在研讀大量國內(nèi)外文獻,對現(xiàn)有測評工具研究基礎上,初步提出了
一個基于TCSEC(GB17859)標準的、可以具體實施的安全操作系統(tǒng)測評框架;并將安全操作系統(tǒng)劃分為系統(tǒng)設計(安全策略模型、基本安全功能、保證映射
、滲透測試、隱通道分析)和實現(xiàn)(系統(tǒng)代碼實現(xiàn)和實現(xiàn)流程)兩方面進行測評,詳細論述了測評依據(jù)、測評原則和測評實施方法,提出了一些行之有效的測
評思路和方法.目前,測評工具分為導航測評工具和自動化測評工具.而在安全操作系統(tǒng)測評領域,手工測評仍然是最主要的測評方式.在測評方法理論指導
下系統(tǒng)地開發(fā)各類測評工具,豐富測評手段.在該課題的研究中,我們開發(fā)了眾多研究工具.在基本功能測試中引入導航測評方法,該工具基于客戶/服務器
模式和數(shù)據(jù)庫來實現(xiàn),可以有效地加快信息收集、整理以及文檔化.研發(fā)自動化測評工具是測評工具設計和實現(xiàn)的主要方向,文章以口令強度自動化測評工
具為例做了說明,該工具依據(jù)字典攻擊原理來實現(xiàn).該文在安全操作系統(tǒng)開發(fā)實踐基礎上,根據(jù)中國該領域發(fā)展現(xiàn)狀,提出的安全操作系統(tǒng)測評框架、測評
思路和測評方法豐富了安全操作系統(tǒng)測評領域的研究,但仍有艱巨的研究工作要做.
本文鏈接：http://d.g.wanfangdata.com.cn/Thesis_Y1339437.aspx
授權(quán)使用：華中科技大學(wfhzkjd)，授權(quán)號：1739c141-6b8f-4d61-ba7e-9ddc0095035e
下載時間：2010年8月24日

網(wǎng)友評論 more

交通安全論文最新內(nèi)容

02-21

合肥市加強混凝土攪拌…

11-01

基于人工神經(jīng)網(wǎng)絡的交…

10-08

關(guān)于對環(huán)境監(jiān)測數(shù)據(jù)審…

10-08

軌道交通項目環(huán)境影響…

10-08

道路工程環(huán)境影響評價…

10-08

高速公路輻射環(huán)境監(jiān)測…

07-22

芻議鐵路選線設計樹立…

07-22

鐵路通信塔安全監(jiān)測系統(tǒng)

交通安全論文熱點內(nèi)容

29871

淺談道路危險貨物運…

25517

城市軌道交通在國外…

22521

淺談如何做到安全文…

21336

道路交通事故成因分…

19555

疲勞駕駛的產(chǎn)生原因…

17672

人為因素對船舶的安…

15662

淺析地鐵中的安全問題

14967

論城市軌道交通安全…

相關(guān)內(nèi)容

戶式輻射冷暖一體化系統(tǒng)工…

電力系統(tǒng)管理及其信息交換…

泛在物聯(lián)應用智能家居系…

信息系統(tǒng)總體控制規(guī)范第1…

IPv6網(wǎng)絡安全測評方法

創(chuàng)想安科網(wǎng)站簡介會員服務廣告服務業(yè)務合作提交需求會員中心在線投稿版權(quán)聲明友情鏈接聯(lián)系我們