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

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中。