Chapter 14 系統保護 (System Protection) 14.1 保護的目的 14.2 保護的原則 14.3 保護的範圍 14.4 存取矩陣 14.5 存取矩陣的製作 14.6 存取控制 14.7 存取權利的取消 14.8 以資格為基礎的系統 14.9 以語言為基礎的保護系統

Chapter 14 系統保護 作業系統中各個不同的行程必須有保護措施的隔開，以免互相影響。為了提供保護措施，必須使用不同方法以確保只有由作業系統獲得適當授權的行程才能在檔案、記憶體分段、CPU和系統的其它資源上操作。 保護(Protection)涉及到控制程式、行程，或使用者對電腦系統所定義之資源的存取機能。此機能必須提供加入控制，以及某些強制性方法的規定。 保密(Confidentiality)是系統完整以及資料保存的信賴度測量。保密保證是比保護更廣泛的課題。

1.保護的目的(Goals of Protection) 電腦系統變得愈來愈複雜，而且在應用上愈來愈普遍，保護其完整性(Integrity)的需求也必須提高。 保護功能被視為多元程式(multiprogramming)作業系統所具備的，使得它能夠使一些不可靠的使用者，能安全地共用相同邏輯命名空間，如檔案目錄或共用相同實體命名空間(common physical name space) 。 目前保護觀念已擴充到各種複雜的系統中共享各種資源的可靠性問題。

2.保護的原則(Principles of Protection) 一個使用原則能在專案各處使用。遵循這項原則可簡化設計決定而且使系統保持一致性和容易瞭解。 保護的時間-測試使用原則是最少特權的原則(principle of least privilege)。它命令程式、使用者和甚至既定系統僅有足夠的特權來執行他們的工作。 遵循最少特權原則的作業系統製作作業系統的特性、程式、系統呼叫和資料結構，以便錯誤或者元件的危害做最小的損害，而且允許最小的損害。 用最少特權的原則管理使用者，需要對每個使用者產生一個個別帳戶(使用者剛好所需的特權)。 在最少特權的原則下的電腦設備製作的電腦，被限制在執行特定的服務，經由特定的處理而且在特定期間內存取特定遠程主機。

3.保護的範圍(Domain of Protection) 一個行程只能存取已經獲得存取權的資源，而且任何時候，它都只需取得完成目前任務所需要的最少資源。 這個要求也就是我們所謂必須知道 (need-to-know)的原則，它能減低一個錯誤行程可能損害系統之程序。 範圍結構(Domain Structure) 保護區(Protection domain)的觀念。每一個行程都必須在設定的保護區中運作。 保護區中設定了物件與在這些物件上的運作功能。這些功能稱之為存取權 (access right)。 保護區也可以說是這些存取權與資源的組合，每一個存取權都是用底下型態的資料序對來表示：<物件名稱，權利集合>(<object-name, rights-set>)。例如，如果在定義域 (domain) D有存取權<file F, {read, write}>，則表示行程在定義域D中，能對檔案F做讀出與寫入的工作;但是它不能對該物件執行其它操作。

定義域與定義域之間不一定要不相交，存取權也可以共用。如圖所示，有三個定義域D1，D2，D3其中存取權<O4, {print}>就被D2與D3所共用。亦即在這兩者其中之一定義域內執行的行程能印O4，在D1中的行程必能執行讀和寫01。換句話說僅在D3中的行程可執行O1。

4.存取矩陣(Access Matrix) 保護模式在觀念上可以把它看成是一個矩陣，稱為存取矩陣(access matrix)。其中列(row)表示定義域，而行(column)則代表處理物件。矩陣內每一個元素，都包含有一些存取權。由於處理物件的名稱已經表示在每一行上，因此在其存取權內，物件的名稱便可以省略不記。對於陣列元素 access(i，j)所定義的，便是一個行程在定義域Di內，對處理物件Oj所能執行的運作項目。

Switch: 授權或權利轉移

在圖 14. 4(a)，一個行程在定義域D2中執行能夠拷貝讀的動作到任何有關於檔案F2的記錄中。因此圖 14 在圖 14.4(a)，一個行程在定義域D2中執行能夠拷貝讀的動作到任何有關於檔案F2的記錄中。因此圖 14.4(a)的存取矩陣能夠被修改成圖 14.4(b)中之存取矩陣。 *: Copy Switch(D2, D3)

Owner 圖 14.5(a)，定義域Dl是F1的所有者，可以加入或移去在行F1 中任何有效的權利，定義域D2是F2與F3的所有者，可加入或移去這兩行中任何有效的權利。圖 14.5(a)的存取矩陣可以修改成圖14.5(b) 中所示的存取矩陣。

拷貝與所有者權利允許一個行程改變一行中的記錄。並且需要一個方法改變一列中的記錄。控制權利只適用於定義域物件。如果 access(i, j)包含了控制權利，則一個在定義域Di中的行程將會從第j列中移去任何一個存取權利。假設在圖14.3中控制權利包含於 access(D2,D4)中，則一個在定義域D2中執行的行程會將定義域D4修改成圖14.6。 Switch(D2, D4)

5.存取矩陣的製作(Implementation of Access Matrix) 5.1 全域表(Global Table) 最簡單製作存取矩陣的方法是建一個含有<domain, object, rights-set>的全域表，當運作M在Di的Oj上運作時，必須在全域表中找尋 <Di, Oj, Rk> (其中M Rk。如果找得到，自然M可執行，不然就跳到(error)錯誤狀態。

5.2 物件的存取串列(Access Lists for Objects) 每個物件串列序對中的元素，其結果如 (domain，right-set)，該元素對物件以一組不是空的存取權限來定義所有定義域。這種觀念加以擴充，加上預設集合(default set)的設定，便可定義出每一個領域所能夠獲許的存取權。 當某一項運作M，試圖在領域Di內，對Oj加以處理時，首先我們到相對應Oj的存取串列內尋找，看是否能夠找到一項元素<Di, Rk>，使得M Rk 。如果找到一項元素，便允許運作 好執行，否則便到預設集合內檢查，如果M是預設存取的一種，那麼我們也允許它祖續執行，否則便不執行，並視為錯誤情況處理。 13

5.3 定義域的資格串(Capability Lists for Domains) 對每一列所代表的領域，建立出在該領域內對每一個物件所允許執行運作之串列，稱之為資格串列(capability list)。每一個物件通常以其實際名稱或位址來表示，稱之為一種資格 (capability)。 要對Oj執行運作M時，行程必須指定Oj的資格 (指標)為參數。如果某行程的資格串列中有此物件的資格項則表示允許該行程使用此物件。 5.4 鎖與鑰匙的技巧(A Lock-Key Mechanism) 鎖與鑰匙 (lock-key)的作法，是一種取用串列與資格串列的折衷作法。 每一物件都有一唯一的位元串列，稱之為鎖。同樣的，每一個定義域也有一唯一的位元串列，稱之為鑰匙。只有在一定義域的鑰匙與物件的鎖相符合時，行程才能在此定義域中對某物件做某運作。 與資格串列的作法相同，任何一個定義域中的鑰匙串列，只能為作業系統所取用，而使用者是不能直接查看或更改其鑰匙串列。

5.5 比較(Comparison) 使用全域表是比較簡單的方法:然而，全域表相當大而且常常無法利用特殊物件或定義域。存取串列是針對使用者的需要而設的，當使用者製造了一個物件時，它可設定那些定義域或那些運作可取用這物件。因為其存取權沒有局部化 (localize)，所以對每一定義域的存取權大小，無法很明確的定義出來。此外，每一取用物件的動作都必須測試是否被允許。在大系統中，串列必定很長，測試與找尋將浪費太多時間。 資格串列並沒有直接對應到使用者的需求;然而，對特殊行程而言，資格串列局部化資料是很有益處的。嘗試存取的行程必須要有存取的資格，然後保護系統只需要查核此資格是否合法。然而，資格的取消可能造成無效。 依鑰匙表的長度不同，此種方法可達到有效率與彈性之效果，鑰匙可以很自由的傳遞於定義域之間，另外，存取之決定權可以經由簡單的改變某些相關於物體之鑰匙而有效的取消。 大多數的系統使用存取串列與資格串列之合併方式。當一個行程第一次去存取一物件，首先會尋找存取串列，如果存取被拒絕，便發出一個例外狀況。否則一個資格便產生並附予行程。以後之存取就依照此資格很容易地顯示是否許可。最後一次存取之後資格就註銷，這種類型用在MIULTICS系統與CAL系統中。

6.存取控制(Access Control) Solaris 10 加強在 SUN 作業系統的保護，明確地藉由角色為其礎的存取控削(role-based access control, RBAC)加少許特權的原則。 SUN 設備環繞在特權上考慮。特權是執行系統呼叫的權利或使用系統呼叫的一種選擇 (如以寫入存取開啟檔案)。被分配到行程的特權，限制行程精確存取行程執行工作的所需。特權與程式也可以分配到角色(Roles)。分配角色給使用者或者扮演以密碼為基礎的角色。在這種方式，使用者可以扮演一個使用特權的角色，誤使用者執行程式，完成指定的任務，如圖 14.7所描述。

7.存取權利的取消(Revocation of Access Rights) - 立即 (immediate)/延後 (delayed):取消是立即發生或延後發生?如果取消延後，能察覺它是何時發生的嗎? - 選擇性的(selective)/一般性的(general):當一個對物件的存取權被取消，它會影響所有對此物件有存取權的使用者嗎?或者能標明某一集合的使用者，對此物件的使用權被取消? - 部份 (Partial)/全部 (total):能否只有一部份集合對此物件的權利被取消?或必須對此物件權利全部取消? - 暫時性的(temporary)/永久性的(Permanent):存取可否被永久取消 (也就是說，取消後的存取權，不再恢復)?或者被取消的存取稍後又被回復?

Revocation of Access Rights Access List – Delete access rights from access list. Simple Immediate Capability List – Scheme required to locate capability in the system before capability can be revoked. Reacquisition(再獲得) Back-pointers(返回指標) Indirection(間接) Keys(鑰匙) 18

8.以資格為基礎的系統(Capability-Based Systems) 8.1 Hydra Hydra是一個以資格為主的保護系統，它提供了相當的彈性。此系統提供了一個固定集合的可能存取權利，系統知道並編譯它。這些權利包括基本形式的存取，像讀、寫或執行一個記憶體分段的權利。然而，另外系統提供使用者去宣稱外加權利的方法。對使用者定義的權利解釋工作由使用者的程式單獨完成，但此系統提供使用者對這些權利的保護，就像系統定義的權利一樣。此系統所提供的這種設施相當有趣，並且構成了在保護技術上一個很顯著的發展。 8.2 劍橋CAP系統 劍橋 CAP系統在以資格為基礎的保護設計上有相當不同的發展。它的資格系統明頓的比Hydra來得簡單與粗淺。然而，更進一步的檢查發現它太容易被使用以提供對使用者定義的物件做安全保護。在 CAP有兩種資格。普通的一種稱做資料資格(data capability)。它能提供物件的存取，但提供的權利只是標準讀寫或個別儲存分段與物件相關的執行。資料資格在 CAP機器中由微程式碼來解釋。第二種資格是所謂的軟體資格(software capability)，它是由CAP微程式碼保護，但不被解釋。它被一個保護的處理程序 (也就是一個特權)解釋，此處理程序可能經由一個應用的程式設計師而被寫成子系統的一部份。

9.以語言為基礎的保護系統(Language-Based Protection) 編譯器為基礎的實行(Compiler-Based Enforcement) 只需要做保護簡單的宣稱，而不是以一串對作業系統處理程序的呼叫寫出。 保護需求的陳述可以與特別的作業系統所提供的設備無關。 實行的方法不必由子系統的設計者提供。 一個宣稱的標示很自然，因為存取特權與資料類型的語言觀念息息相關。