安全體系結構的七個設計原則。

FLASK體系結構的主要特點。

FLASK體系結構中客體服務器OM和安全服務器的基本組成和作用。

LSM框架的特點，及其對內核的主要修改

?

第一章安全體系結構的七個設計原則

1.安全體系結構定義：安全體系結構描述的是一個系統如何組織成一個整體以滿足既定的安全性要求

2.安全體系結構組成：1）?詳細描述系統中安全相關的所有方面。這包括系統可能提供的所有安全服務及保護系統自身安全的所有安全措施，描述方式可以用自然語言，也可以用形式語言。2） 在一定的抽象層次上描述各個安全相關模塊之間的關系。這可以用邏輯框圖來表達，主要用以在抽象層次上按滿足安全需求的方式來描述系統關鍵元素之間的關系3） 提出指導設計的基本原則。根據系統設計的要求及工程設計的理論和方法，明確系統設計各方面的基本原則。4）提出開發過程的基本框架及對應于該框架體系的層次結構。描述確保系統安全需求的整個開發過程的所有方面

3. 安全體系結構作用：

安全體系結構在整個開發過程中必須扮演指導者的角色。①、要求所有開發者在開發前對安全體系結構必須達成共識; ②、在開發過程中自覺服從于安全體系結構; ③、在工程實現階段也必須在體系結構的指導原則下進行工作。

因此：1）安全體系結構應該只是一個概要設計，而不是系統功能的描述。2）安全體系結構應該有模塊化的特性。

4.七個設計原則：

(1)從系統設計之初就考慮安全性:因此在考慮系統體系結構的同時就應該考慮相應的安全體系結構。

(2)應盡量考慮未來可能面臨的安全需求

(3)實現安全控制的極小化和隔離性:并不是建立的控制越多就越安全，最小開銷達到最大的安全系。安全組件與其他組件隔離開來。

(4)實施極小特權 ：不應該讓某些用戶具有過高的權限。

(5)安全相關功能必須結構化：具有一個好的體系結構，安全相關的部分能夠被確定，總體上能夠很快對系統檢查。對安全功能由清晰的易于規范的接口。

(6)使安全性能“友好” ：增加安全性不要給合法用戶帶來負擔

(7)使安全性不依賴于保密：可以告訴用戶攝像頭在哪，可以告訴用戶消防器在哪。

第二章FLASK體系結構

1.FLASK體系結構對策略靈活性的支持應包含以下內容：1）支持多種安全策略；2）可實現細粒度的訪問控制；3）能夠確保訪問權限的授予與安全策略保持一致；4）能夠撤回先前已授予的訪問權限。

2. FLASK體系結構由客體管理器OM和安全服務器SS組成。（1）OM負責實施安全策略（2）SS負責安全策略決策。

FLASK描述了客體管理器和安全服務器之間的交互，以及對它們內部組成部分的要求。

3. 客體管理器OM基本組成

第一，為客戶端提供訪問決策、標記決策和多實例化決策的接口。（用戶想訪問某個資源，OM給用戶提供相關功能、用戶要創建某個新資源，OM給它打標簽，賦予安全屬性、多實例化的要求）

訪問決策確定一個訪問是否被允許。

（2）標記決策確定應該授予客體何種安全屬性：

（系統的安全策略是可變的，所以主客體打的安全標簽也是可變的，當系統策略變化的，系統仍然可以支持變量的類型。例如C語言中void指針強制轉為int）

FLASK體系結構為解決多種需求之間的沖突提供了兩個策略獨立的數據類型來標識客體。①security context, 一種可變長串，它可以被任何理解安全策略的應用程序或者用戶來解釋。②security identifier (SID), 由FLASK定義的一個具有固定長的值，它只可以由SS解釋，并由SS映射到特定的安全上下文

?

多實例化決策確定當前多實例化資源中哪一個成員應該被訪問。：

通過多實例化某資源來按組劃分終端實體，使得每個組中的實體能共享該資源的相同實例，來限制固定資源在終端實體間的共享。

例如：多級安全的Unix/Linux系統經常劃分/tmp目錄，為每個安全級保留獨立的子目錄。

第二，提供一個訪問向量緩沖器AVC (Access Vector Cache), 暫時緩存訪問決策結果，以提高系統效率。（例如某個請求，被允許過，下次訪問，可以直接咨詢AVC，提高訪問決策效率）

第三，提供接收和處理安全策略變動通知的能力。：

支持策略吊銷：

安全策略的改變要求在OM和SS之間進行協調以確保它們的策略表達是一致的。 有效的原子性是通過系統中加入以下需求獲取的：

???? 1）在策略改變完成后，OM的行為必須反映這個變化。如果沒有后續的策略變化，不允許需要被吊銷許可的受控操作執行。

???? 2) OM必須采用實時的方式完成策略的改變。

為滿足1），OM和SS之間應該提供一種協議，分三步：

第一，SS讓所有的OM注意到以前策略任何部分發生了改變

第二，每個OM更新內部狀態以反映這些改變

第三，每個OM讓SS注意到改變已完成

OM的實時性要求使協議提供的原子性合理。

吊銷請求不能被不可信軟件行為任意地延遲。

每個OM一定能夠更新自己的狀態，而不會受到客戶的隨意阻撓。

當這種實時性要求被推廣到系統級策略變更時，它將牽涉到系統的另外兩個組件：

微內核，為OM和SS之間提供實時的通信；

調度程序，為OM提供CPU資源。

Fluke API的兩個性質簡化了微內核的吊銷機制：

它提供了線程狀態的及時的和完全的輸出

確保所有內核的操作或者是原子性的，或者是可清楚地細分為用戶可視的原子性階段。

第一條性質允許內核吊銷機制訪問內核的狀態，包括正在運行的操作。吊銷機制可以安全地等待正在運行操作的結束或者為保證及時性而重啟它。

第二個性質允許將FLASK的許可檢查嵌入到與他們控制的服務一樣的原子性操作中，這樣可避免吊銷請求完成之后再出現該服務。

4. Security Server安全服務器

安全服務器需要提供安全策略決策、保持SIDs和安全上下文之間的映射、為新創建的客體提供SIDs、提供成員客體的SIDs、控制OM的AVC。此外大多數SS的執行會對載入和改變策略提供相應的功能。

除了OM中的AVC機制以外，對SS提供一個自己的緩存機制保存訪問計算的結果，可以縮短它的反應時間。

1. SS的強制性:SS是一個典型的策略強制執行者。表現在：

(1)如果SS對改變策略提供了接口，它必須對主體能夠訪問的接口強制執行安全策略。

(2)必須限制能夠獲取策略信息的主體。這在一個策略中的許可請求可改變策略時顯得非常重要，如:一個動態的利益沖突策略。如果策略信息的機密性很重要，OM必須負責為它緩存的策略信息提供保護。

2. SS中的安全策略管理:

被Flask安全服務器封裝的安全策略是通過對它的代碼和一個策略數據庫的綁定來定義的。

(1)任何能夠被原始策略數據庫語言表達的安全策略，可以僅僅通過改變策略數據庫來實現。

(2)對其它安全策略的支持需要對安全服務器內部的策略框架進行改變，可以改變代碼或者完全更改安全服務器。

(3)有一點值得注意的是即使需要對安全服務器的代碼進行改變，也不需要對客體管理器進行任何變動。

第三章LSM框架

第一部分：LSM的特點：

1.LSM簡介：由Linus Torvalds本人帶頭發起。LSM為主流Linux核心提供了一個輕量級的，通用目的的訪問控制框架，使得很多不同的訪問控制模型可以作為可加載模塊（Loadable Kernel Module）來實現。

2. Linus本人認為該框架的特點為:

（1）真正通用，使用不同的安全模型的實施僅僅是加載不同的核心模塊；（2）概念上簡單，最小的擴散，有效；（3）能夠作為一個可選安全模塊，支持現有的POSIX.1e權能邏輯。

另一方面，各種不同的Linux安全增強系統對Linux安全模塊（LSM）提出的要求是：能夠允許他們以可加載內核模塊的形式重新實現其安全功能，并且不會在安全性方面帶來明顯的損失，也不會帶來額外的系統開銷。?

第二部分LSM的5處修改（P168）

【內核關鍵數據結構的修改 ，鉤函數的調用 ，新增安全系統調用 ，安全模塊管理 ，獨立capability模塊】

（1）??? 在特定的內核數據結構中加入安全域：加載時候要賦值，卸載時候要釋放，void*security

（2）??? 在內核代碼中的管理域和實現訪問控制的關鍵點介入對鉤子函數的調用:原來的內核里面加入鉤函數，LSM提供了153個鉤函數。

（3）??? 加入一個通用的安全系統調用：可以靈活擴展——提供新的系統調用

asmlinkage long sys_security (unsigned int id, unsigned intcall, unsigned long *args).

?? @ id: moduleid.? Can use id to help identifywhich?? module user app is talking to.

?? @ call: callidentifier

?? @ args: arg listfor call

實現系統調用分發，便于擴展新的系統調用

（4）??? 提供函數允許內核模塊注冊為安全模塊，或者注銷一個安全模塊

內核初始啟動時是一般系統的狀態，加載的是dummy模塊（支持傳統的超級用戶模式）

主模塊管理

加載：register_security:實現security_ops和其引用的鉤函數對應。該機制用于設置主模塊，負責每個鉤函數函數的最終決策。

卸載：unregister_security:返回初始狀態。

模塊堆棧管理：mod_reg_security，mod_unreg_security

使其后的安全模塊可以向已經第一個注冊的主模塊注冊和注銷，但其策略實現由主模塊決定：是提供某種策略來實現模塊堆棧從而支持模塊功能合成，還是簡單的返回錯誤值以忽略其后的安全模塊。

這些函數都提供在內核源代碼文件security/security.c中

（5）??? 將大部分權能邏輯移植為一個可選的安全模塊

Linux中已實現Posix. 1e 的權限機制的子集的支持，LSM將其獨立出來作為安全模塊實現，并可以和其他安全模塊堆棧使用。

第四章GFAC

GFAC假設所有訪問控制策略都可以視為由安全屬性構成的安全規則的集合，因此定義三個概念：

權威(Authorities)：是一個授權個體，它可以定義安全策略、確定安全信息和給安全屬性賦值；

安全屬性(Attributes)：用于訪問控制決策的主體、客體的屬性；

規則(Rules)：對安全屬性和其它安全信息之間相互關系的形式化描述，這種關系是安全策略的反映。規則由權威制訂。

GFAC中將安全屬性和其它訪問控制數據稱為訪問控制信息(ACI, AccessControl Information)，而將實現系統安全策略的規則稱為訪問控制規則(ACR, Access Control Rules)。

GFAC將訪問控制分為兩部分：

AEF(Access controlEnforcement Facility)訪問控制實施部分。它依據ADF的決策結果，控制訪問是否進行。

ADF(Access controlDecision Facility)訪問控制決策部分。它實施系統的各種安全策略和元策略（綜合各安全策略的判定結果后決定是否允許訪問）。ADF在進行決策時，需要參考的訪問控制信息（描述主、客體的安全屬性）和訪問控制規則（描述安全屬性之間的關系）保存在ACI和ACR中。

總結

以上是生活随笔為你收集整理的安全体系结构与七个设计原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。