PP 目錄

圖 4.6：SuSE Linux TSF 與非 TSF 軟體示意

圖 4.7：SuSE Linux 核心子系統及其交互工作示意

系統呼叫介面

（System Call Interface）

稽核 (Audit)子系統 過程

(Process)子系 統 核心模組

子系統

過程間通訊(Inter-Process Communication，簡稱

IPC)子系統Subsystem

檔案與輸入／

輸出子系統 網路子系統

設備驅動子系統 記憶(Memory) 子系統

使用者 核心 應 用 ( A p p l i c a t i o n s )

O S 指 令 ( c o m m a n d s ) 例 ： v i , g r e p , l i n e

p r i n t e r ( 子 系 統 )

O S 指 令 ( c o m m a n d s ) 例 : l o g i n , p a s s w d ,

s u , c r o n d

核 心 ( K e r n e l ) 硬 體 ( H a r d w a r e )

說 明 ： 非 T S F T S F

4.3、Linux 與角色基存取控制：

一般而言，Linux 核心之安全根基於過程與能力(Process and Capability)、檔案系 統與封包控制之安全性，其中檔案系統及封包控制和一般常見之方法類似，過程與能 力方面，簡述於后【78】：

Linux 中的使用者行為都是藉由過程(Process)來完成，一個過程通常具有以下幾 個屬性：

(1).RUID，RGID：真正用來執行過程的 UID 及 GID。

(2).EUID，EGUID：用來做權限檢查。

(3).SUID，SGID：用來做權限轉換。

(4).umask：存取控制的設定。

(5).limits：資源使用的限制。

(6).FSUID，FSGID：用來做檔案系統存取權限的檢查，通常都會等於 EUID、EGID。

(7).capabilities：POSIX capability 資訊。

基於安全的考量，Linux 給予一般使用者盡可能低的權限，而把全部的系統權限 賦予一個單一的帳戶－root。Root 用來管理系統、安裝軟體、管理帳戶、執行某些服 務等。但一般使用者很多的執行動作也需要 root 權限，此時可透過 setuid 來達到目 的。但這種依賴單一帳戶執行權限的運作方式，卻增加了系統面臨的安全威脅。因為 某些程式需要 root 權限可能只是為一個很簡單的執行目的而已，例如：bind 到特定 port、打開一個只有 root 權限可以開啟的檔案等。但這些程式可能存在安全漏洞，若 該程式不是以root 的權限執行時，其存在的漏洞對系統造成的安全威脅就會降低。

Linux 從 2.1 版開始，核心開發人員在 Linux 核心中加入了能力(Capability)的概 念，其目的就是降低過程在執行某些動作時對 root 帳戶的依賴。從 2.2 版本的核心開 始後，就可以用一些能力的基本功能。傳統 UNIX 的信任模型非常簡單，就是「root 對一般使用者」模型。在這種模型中，一個過程不是什麼都能做，就是幾乎什麼也不 能做，這取決於過程的 UID。很顯然這樣對系統安全存在很大的威脅，UNIX 系統中常 見之的SUID 的安全問題就是由這種信任狀模型造成的。

過程與能力之設定可以降低類似 SUID 等的安全風險，系統管理員為了系統的安 全可以刪減 root 的能力，這樣即使是 root 也無法進行某些執行動作。而這個過程又是 不可逆的，也就是說如果一種能力被刪除，除非重新啟動系統，否則即使 root 也無法 重新加入被刪除的能力。

能力是一種規範，它定義了能夠對某個目標進行之所有操作行為，以及允許在這 個目標上進行的操作行為。能力的操作動作包括：複製某個能力、程序間某個能力之 遷移、修改某個能力以及取消某個能力等。目前為止，各種作業系統對能力(Capability) 的應用程度並不相同。

舉例來說，File Descriptor 就是一種能力，當使用者利用開啟(Open)這個系統呼 叫(System call)來獲得檔案的讀或寫權限，如果 Open 執行成功，系統的核心就會建立 一個File Descriptor。如果收到讀或寫的請求，核心就使用這個 File Descriptor 作為一 個資料結構的索引，檢查相關的操作是否已被允許。

基於單一 root 之脆弱性的風險；因此，訂定資訊安全政策時，通常會建議管理者 使用 Linux 核心定義的這些能力，依系統需求分割 root 的權限，避免因系統中 root 的 權限過大所造成的安全風險【42】，表

4.4

是Linux 中之能力表列【42, 77~78】。

表 4. 4：Linux 之能力表列

能力名稱(Capability Name) 代號 說明 CAP_CHOWN 0 允許改變檔案的所有權 CAP_DAC_OVERRIDE 1 忽略所有DAC 的存取

CAP_DAC_READ_SEARCH 2 忽略所有對讀、搜索操作的限制

CAP_FOWNER 3 如果檔案屬於過程的UID，就取消對檔案的限制 CAP_FSETID 4 允許設置setuid

CAP_FS_MASK 0x1f 用來決定 fall back 到 suers()或 fsuers CAP_KIL 5 忽略過程間傳送signal 時檢查 uid 的限制 CAP_SETGID 6 允許改變群組ID

CAP_SETUID 7 允許改變使用者ID

CAP_SETPCAP 8 允許向其它過程轉移能力及刪除能力 CAP_LINUX_IMMUTABLE 9 允許修改檔案的IMMUTABLE 和

APPEND-ONLY 屬性

CAP_NET_BIND_SERVICE 10 允許應用程式bind 小於 1024 的 port CAP_NET_BROADCAST 11 允許網路Broadcast 和 Multicast

CAP_NET_ADMIN 12 允許執行網路管理任務：socket、防火牆等 CAP_NET_RAW 13 允許使用raw socket

CAP_IPC_LOCK 14 允許鎖定IPC

CAP_IPC_OWNER 15 忽略IPC 所有權檢查 CAP_SYS_MODULE 16 插入和刪除核心模組 CAP_SYS_RAWIO 17 允許對ioperm/iopl 的存取 CAP_SYS_CHROOT 18 允許使用chroot() system call CAP_SYS_PTRACE 19 允許trace 任何程序

CAP_SYS_PACCT 20 允許設定過程 accounting

CAP_SYS_ADMIN 21 允許執行系統管理任務，如：檔案系統控制、

quota、設定網域名稱等 CAP_SYS_BOOT 22 允許重新啟動系統 CAP_SYS_NICE 23 允許提升nice 值 CAP_SYS_RESOURCE 24 忽略資源限制 CAP_SYS_TIME 25 允許改變系統時間 CAP_SYS_TTY_CONFIG 26 允許設定TTY Device CAP_SYS_MEM DUMP 27 允許傾印任何記體體區塊 CAP_SYS_EERPOM 28 允許存取EEPROM CAP_SYS_PSDUMP 29 允許列出所有執行過程 CAP_SYS_SIGTRIP 30 允許執行trace trap

CAP_MKNOD 31 允許使用mknod() system call CAP_LEASE 32 Allow taking of leases on files

現有之 Linux 作業系統以傳統 Bell-LaPadula【42, 77~78】安全機制為主流，其 對 資 料的完整性等安全需求有所 不足的，因此美國國家安全局(National Security Agency，簡稱 NSA)在 2001 年的 Linux 核心高峰會上，以 Linux 為架構，提出研究發 展近 10 年之安全增強 Linux 機制：SE Linux【27】，使用較具有彈性的 flask【77】

框架，將 Linux 安全等級提升至 EAL4，同時具有資料標記及強制的存取控制【51】，

號稱是最安全的 Linux 作業系統。SE Linux 可以被用來規範最小特權，保護過程與資 料的完整性、機密性及可歸責性宜有之職責區隔機制等。

SE Linux 系統之安全體系結構如圖

4.8

所示，封裝於安全服務中之政策(Policy)與 具 體 執 行 實 施(Enforcement) 的 對 象 管 理 器 兩 部 分 組 成 ； 首 先 以 政 策 語 言 (Policy Language)提供系統管理者來制定安全政策(Security Policy)，並由核心層存取控制檢 查。SE Linux 同時提供了範例政策(Example Policy)，並允許使用者利用型態強化 (Type Enforce，簡稱 TE)與角色基存控制(Role-Based Access Control，簡稱 RBAC) 及可選之多級別安全性(Optional Multilevel Security)方式來客製化系統。

圖 4.8：SE Linux 安全體系結構圖

SE Linux 系統中關於安全的請求和決策有三種情況【27, 51, 77】：

(1).標示決策(Labeling Decision)：確定一個新的主體或受體採用什麼安全標示(如創建 受體時)；

(2).存取決策(Access Decision)：確定主體是否能存取受體的某種服務(如文件讀寫)；

(3).多 模 態 決 策 (Polyinstantiation Decision) ： 確 定 一 個 過 程 在 訪 問 某 個 polyinstantiation 受 體 時 ， 可 不 可 以 轉 為 另 一 個 過 程 ( 如 從 login_t 轉 到 netscape_t)。

SE Linux 設計精神主要由根據特定目的定義類別(Domain Type)，限制其存取物 件類別之 TE 與如圖

4.9

所示 RBAC 以及可選的多級別安全性(Optional Multilevel Security)混合制定而成。

圖 4.9：SE Linux 為以角色為基底的存取控制

政 策 執 行

對 象 到 S I D 映 射 對 象 管 理 器

對 象 請 求

查 詢

決 策

實 施 策 略 客 戶 機

安 全 政 策

S I D 到 安 全 上 下 文

的 映 射 安 全 服 務 器

使 用 者 （ U S E R ）

定 義 類 別 受 體 類 別

（ O b je c t T y p e ）

角 色 （ R o le ）

SE Linux 複雜的安全政策固然提供管理者很大的安全制訂彈性，但因 SE Linux 語法複雜且龐大，例如由SE Linux 所提供的政策範例(Example Policy)中，至少包含 3 個角色，29 個 object class，22 個 attribute，115 個 permission，253 個 type，及上 萬行的語法，因此在使用 SE Linux 時所面臨設定及管理安全政策上的複雜及困難，也 衍生出許多相關研究，例如所設定的規則是否符合使用者所要求的目標等；如欲善用 SE Linux，宜先了解 RBAC。

4.3.1、RBAC 簡介：

組織中，每位工作人員所擁有的職權與職責是基於其所擔任的角色而定，而非工 作人員本身。在過去我們採用「隨意性存取控制」(Discretional Access Control，簡稱 DAC)與「強制性的存取控制」(Mandatory Access Control，簡稱 MAC)做存取控制的 控管，然而這兩種存取控制控管模式隨著組織結構的日益複雜化和安全需求的提高已 不足以適用。因此，多位學者提出了“以角色為基礎”的想法，透過角色本身所擁有的職 權與責任、職位與工作等角色之間的互動關係與組織管理政策的結合，提出了「以角 色為基礎的存取控制管制」(Role- Based Access Control，簡稱 RBAC)的參考模式

【59】。

角色本身代表了職權與責任等的組合，例如組織定義了「人事部經理」這個角 色，規範出它應負的責任，即公司人事及薪資的管理，同時也授與它相對的權力，如 人事任用決定權。在更完整的職務模式(Role Model)中包含了角色之間的關聯性，以及 其限制條件【11】。在 1996 年提出並形成共識之 RBAC96 模式【59】依照應用的層 面分為RBAC0、RBAC1、RBAC2、和RBAC3，其關聯性如圖

4.10

所示。

圖 4.10：以角色為基礎的存取控制模式

RBAC 中之基本模式定義了使用者(User)、角色(Role)及權限(Permission)三者之 間的關聯。在角色的繼承模式中包含了基本模式，另外加入角色繼承的觀念，在角色 的限制方面，RBAC96 認為在此可加入組織內部的控制方法，如權責區分、情境限制 等，以符合大部份組織長久以來所規範的管理原則。在綜合模式中，將以上三者做整 合，提供完整的角色存取控制方案。

在 RBAC0中定義了三個主要的個體(Entity)，分別為使用者(User)、角色(Role)、

以及權限(Permission)三者。另外也納入連線(Session)的觀念，其關係如圖

4.11

所 示：

R B A C3

綜 合 模 式

( C o n s o l i d a t e d M o d e l )

R B A C1

角 色 的 繼 承 模 式

（ R o l e H i e r a r c h y ）

R B A C2

角 色 的 限 制

（ C o n s t r a i n t s ）

R B A C0

基 本 模 式

（ B a s e M o d e l ）

圖 4.11：以角色為基礎的存取控制管制基礎架構

使用者可透過角色的指派取得其所擔任的職位應有的職權與責任，例如吳茲仁先 生為採購部主管，那麼他便可以經由角色的指派取得採購部主管的權力。而每一個角 色可以執行的作業程序則在權限的指派來做設定；例如採購部主管的權限為核准採購 單，因此我們便可以將“核准採購單”這個作業程序指定給“採購部主管”這樣的角色。另 外連線(Session)也是一種使用者與角色之間的關聯性，不同的是它是在動態執行時所 產生，代表了使用者目前在執行中的角色集合。

在 RBAC1中除了 RBAC0對角色的基本定義外，納入了組織內角色承受的概念；

也就是在組織中職位高的員工可以繼承職位低的員工的工作。舉例來說，在電腦軟體 部門裡，主管除了可以執行相關的管理工作外，也可以做程式撰寫的工作(此為程式設 計師的工作內容)，如圖

4.12

所示。

圖 4.12：RBAC 中角色之繼承概念

在 RBAC2中納入了許多角色實行時的限制條件，這些限制條件在組織的運作上組 成 了 重 要 的 控 制 點 ， 用 以 實 現 傳 統 企 業 的 內 部 控 制 原 則 。 其 中 包 括 權 責 區 分 (Seperation of Duties)、組織取得的必備條件限制(Prerequisite Condition)、指派組織 的數量限制(Cardinality Constraint)、被啟動的組織限制(Session Limited)等。

在 RBAC 理論中，由於考慮到組織的實際需求，因此相較於傳統的存取控制理論

在 RBAC 理論中，由於考慮到組織的實際需求，因此相較於傳統的存取控制理論

在文檔中 數位社會資訊安全密碼政策初探 (頁 47-59)