用戶定義的角色
在這個部分中，我們將介紹用戶定義的角色。
對用戶定義的角色進行規劃
正如我們在第 1 部分“RBAC 中的預定義角色”中所討論的，AIX V6 中包括三種預定義角 色。這些預定義角色為劃分管理職責提供了一種建議的方法。
可以對這些預定義角色進行修改或者刪除，對於不同的環境，也可以創建一些合適的、新的角色。
注意：ISSO、SA 和 SO 角色由 Trusted AIX 使用。如果您的環境中包括 Trusted AIX，那麼您可能 會希望通過使用用戶定義的角色來自定義您的 RBAC 環境。
盡管這些預定義角色適用於各種管理需求，但有時候，需要對職責進行進一步、更細粒度地劃分。在 這種情況下，增強的 RBAC 允許創建用戶定義的角色。
在創建用戶定義的角色時，應該考慮下面的幾個要點：
角色的名稱
角色的名稱應該包括某些描述、或者對該角色功能的見解。角色名稱限制為不超過 63 個可打印的字 符。
授權
考慮應該向該角色分配哪些授權。
子角色
考慮該角色是否應該包含子角色。子角色是一種非常方便的方法，用於為用戶定義的角色分配一個或 者多個預先存在的角色。
身份驗證
在通過 swrole 命令使用角色的時候，用戶是否必須進行身份驗證。
創建一個用戶定義的角色
AIX V6 中包括下面的幾種角色和 KST 管理命令：
mkrole
創建一個新的角色。當系統運行於增強的 RBAC 模式時，可以立即將角色數據庫中創建的角色分配給 用戶，但出於安全的考慮，應該在通過 setkst 命令將數據庫發送到內核安全表 (KST) 之後再使用這些 角色。
rmrole
刪除一個現有的角色。當系統運行於增強的 RBAC 模式時，從角色數據庫中刪除的角色將仍然存在於 KST 中，直到使用 setkst 命令更新 KST。
lsrole
lsrole 命令用於列出角色數據庫中可供使用的角色定義。當系統運行於增強的 RBAC 模式時，出於系 統安全的考慮，角色數據庫中的信息可能與 KST 中的信息有所不同。要查看 KST 中角色數據庫的狀態， 可以使用 lskst 命令。
chrole
更改或者修改一個現有的角色。當系統運行於增強的 RBAC 模式時，出於安全的考慮，在通過 setkst 命令將角色數據庫發送到 KST 之前，對數據庫所做的修改將不能使用。
swrole
swrole 命令可用於激活一個角色。激活一個角色也稱為“交換”角色。用戶只能激活已經 分配給他的那些角色。
setkst
更新增強的 RBAC 內核安全表。
RBAC 安全檢查在內核級執行，因此如果對 RBAC 安全數據庫進行了任何用戶級更改，那麼在將這些更 改用於 RBAC 安全檢查之前，需要將它們更新到 KST 中。
lskst
列出內核安全表的內容。RBAC 安全數據庫的內容與 KST 並不是始終相匹配的，因此 lskst 命令可用 於列出、或者比較 KST 和用戶級 RBAC 安全數據庫。
在前面的部分中，我們為 oper1 分配了 so 角色。這個 so 角色允許 oper1 用戶執行 shutdown 和 reboot 命令，除此之外，還允許執行其他幾個特權命令，包括 kill 命令。
可以考慮下面這個場景：在執行了一次審核之後，安全控制人員請求我們限制 oper1 用戶的權限，以 便他只能執行 shutdown 和 reboot 命令，而不能執行其他的特權命令。因為不存在任何僅包括這兩個命 令的預定義角色，所以我們必須創建一個用戶定義的角色。
要創建用戶定義的角色，請遵循下面的步驟：
1. 以 root 或者角色管理用戶的身份登錄。
我們將使用 smitty mkrole 快速路徑。
此時將顯示下面的條目字段：
角色名 (Role Name)
這是用戶定義的角色將使用的名稱。
這個用戶定義的角色將用於執行關閉和重新啟動操作，因此我們將其名稱定義為 shutdown_reboot。
角色 ID (Role ID)
唯一的角色標識編號。如果將其保留為空白，那麼將分配下一個可用的角色編號。建議的方法是，使 用下一個可用的角色編號。
授權 (Authorizations)
應該分配給該角色的授權。
這些授權可能是系統定義的、或者用戶定義的授權。
在第 1 部分中，我們已經確定了所需的授權是 aix.system.boot.shutdown 和 aix.system.boot.shutdown。通過使用 F4 鍵，可以從授權列表中選擇這兩個授權。
角色列表 (Role List)
如果需要的話，為該角色添加的子角色列表。
組 (Groups)
如果需要的話，分配該角色的組列表。
SMIT 屏幕 (SMIT Screens)
定義這個角色可以訪問的 SMITTY 屏幕。“*”通配符用於定義所有的屏幕 (ALL)。
可見性 (Visibility)
指定角色對系統的可見性狀態。
描述 (Description)
角色的描述。
圖 1 smitty mkrole 命令
在輸入了 SMIT 屏幕中的各個字段條目之後，選擇 Enter。
除了使用 SMIT 屏幕之外，另一種方法是使用 mkrole 命令。
圖 2 顯示使用與圖 1 中相同的輸入參數的 mkrole 命令。
圖 2 mkrole 命令
2. 現在已經定義了用戶定義的角色 shutdown_reboot。
在圖 3 中，我們使用 lsrole 命令列出 shutdown_reboot 角色。
該角色僅包含 aix.system.boot.reboot 和 aix.system.boot.shutdown 兩種授權。
通過限制可用於這個角色的授權，我們可以執行最少特權原則，為 oper1 用戶授予適當的權限，使該 用戶只能訪問完成其工作職能所需的那些命令。
圖 3 lsrole——列出用戶定義的角色
3. 為用戶分配角色。
可以使用 chuser 命令分配 RBAC 角色。
圖 4 顯示在將 shutdown_reboot 角色分配給 oper1 用戶之前，lsuser 命令的輸出。現在，已經為 oper1 用戶分配了 so 角色。
圖 4 對定義了 so 角色的用戶 oper1 執行 lsuser 命令
chuser 命令並不能為現有的角色追加新的角色。如果已經為 oper1 用戶分配了現有的角色，那麼 chuser 命令的新角色值中需要包括這些現有的角色。
圖 5 顯示使用 chuser 命令將 shutdown_reboot 角色添加到 oper1 用戶。
圖 5 使用 chuser 命令將 shutdown_reboot 角色分配給 oper1 用戶
4. 更新內核安全表。
當運行於增強的 RBAC 模式時，將在 AIX 內核中執行授權和權限檢查。如果對 RBAC 角色表進行了添 加或者修改，那麼在這些修改生效之前，需要將 RBAC 安全數據庫更新到 AIX 內核中。
AIX V6 和增強的 RBAC 引入了 setkst 命令，以便將 RBAC 表更新到 AIX 內核中。
setkst 命令將讀取 RBAC 安全數據庫文件，並將其中的信息加載到內核安全表 (KST) 中。在缺省情 況下，會將所有的安全數據庫發送到 KST。
圖 6 顯示在使用 setkst 命令將 RBAC 安全數據庫文件更新到 KST 中之前，oper1 用戶執行 rolelist 命令的情況。
圖 6 在沒有更新 KST 的情況下使用 rolelist 命令
盡管已經向 RBAC 安全數據庫定義了用戶定義的角色 shutdown_reboot，但在新的角色定義之後，還 沒有使用 setkst 命令對 KST 進行更新。根據位於 KST 中的 RBAC 安全信息執行所有的 RBAC 安全檢查 ，所以安全檢查將會失敗，這是因為 KST 中尚未包含 shutdown_reboot 角色。
執行 setkst 命令，將 RBAC 安全數據庫更新到 KST 中。
setkst 還將對 RBAC 安全數據庫表進行有效性檢查。如果碰到錯誤，根據錯誤的嚴重程度，setkst 命令將列出錯誤並繼續運行、或者在不更新 KST 的情況下退出程序。
圖 7 顯示 setkst 命令。在成功完成 setkst 命令之後，已經對 KST 進行了更新，並且新創建的角 色將可供使用。
圖 7 setkst 命令
注意：在將角色分配給用戶之後，可能沒有對 KST 進行更新。在對 KST 進行更新之前，用戶將不能 使用該角色。
5. 激活該角色。
在缺省情況下，直到用戶登錄系統並使用 swrole 命令激活角色，該角色才處於活動狀態。如果 oper1 用戶希望在不激活 shutdown_reboot 角色的情況下執行 shutdown 命令，那麼 shutdown 命令將 試圖以 oper1 用戶進行執行。
要激活一個角色，我們可以使用 swrole 命令。
swrole 命令將啟動一個新的角色會話 Shell，該角色會話 Shell 需要用戶使用他們的密碼進行身份 驗證。
在對密碼進行了身份驗證之後，將激活該角色，並且將為該角色定義的授權中所包含的命令作為特權 命令來執行。
在圖 8 中，我們執行了 swrole 命令。swrole 命令需要使用角色名稱作為參數，因此我們執行了命 令 swrole shutdown_reboot。這個操作將激活 shutdown_reboot 角色。
在激活了 shutdown_reboot 角色之後，就可以使用 rolelist -ea 命令來列出有效的角色和授權。
圖 8 swrole 命令
6. 現在，oper1 用戶的 so 角色已經處於活動狀態，並且可以執行 shutdown 和 reboot 命令。
通過為用戶 oper1 添加 shutdown_reboot 角色，我們可以在不訪問 root 用戶或者成為 shutdown 組成員的情況下，執行 shutdown 和 reboot 程序。此外，不需要更改文件對象 DAC。
在圖 9 中，我們以 oper1 用戶執行 shutdown 命令。
圖 9 以 oper1 用戶執行 shutdown 命令
系統定義的和用戶定義的授權
在這個部分中，我們將討論增強的 RBAC 授權，並概括和描述創建用戶定義的授權所需的過程。
對用戶定義的授權進行規劃
AIX 5L 的 RBAC 實現提供了兩種類型的授權：
系統定義的授權——預定義的、並且作為 AIX 5L 安裝過程的一部分而進行安裝的授權。 系統定義的授權是不能進行修改的。
用戶定義的授權——不屬於系統定義的授權的任何授權。在創建用戶定義的授權之後，可 以對其進行修改或者刪除。
在授權層次結構中，系統定義的授權都使用“aix.”名稱作為前綴。系統定義的授權不能 進行修改或者刪除。在系統定義的授權層次結構中，不能包括用戶定義的授權。對於這種情況的說明，請 參見下面的圖 10。
圖 10 授權命名約定
用戶可以定義他們自己的授權層次結構，並將其分配給不同的角色。
這種層次結構的基本名稱必須是除“aix”以外的其他名稱。
用戶定義的授權支持與系統定義的授權使用相同的層次結構概念。
在創建用戶定義的授權時，應該考慮下面的幾點限制：
用戶定義的授權必須在新的頂層父節點之下進行定義。不能在現有的“aix.”層次結構之 下創建用戶定義的授權。用戶定義的授權可以不是系統定義的“aix.”層次結構的子節點。
一個授權名最多可以由 63 個可打印的字符組成，但其中不允許使用空格。
一個授權最多可以具有 8 個父層次。
一個授權可以具有任意多個直接子節點，但是只能具有一個直接父節點。兩個獨立的授權不能具有相 同的直接子節點。
在創建用戶定義的授權時，應該考慮將要使用的命名約定。授權的名稱應該包括某些描述、或者對該 授權用途的理解。
在創建用戶定義的授權時，建議使用下面的語法：
vendor_name.product_name.function.function1.function2…
表 1 進一步說明了在創建用戶定義的授權時，建議使用的命名格式。
表 1 為用戶定義的授權進行命名的建議語法
供應商名稱 標識生產或者提供這個軟件模塊的供應商的名稱。 產品名稱 簡要的產品名稱。 功能、功能 1、功能 2…… 這些字符串用於表示使用 RBAC 進行管理的功能。另外，在定義這些字符串的時候，它 們提供了一種層次結構的表示形式，以表現這些功能的組織方式。ibm.tsm.managment.admin.stgpool 就是這種命名約定的一個示例。
可以潛在地創建這個用戶定義的授權，以表示 IBM Tivoli® Storage Manager 存儲池設備類別的 管理方面的內容。
使用這樣的格式，將有助於避免在多個軟件組件之間出現授權命名的沖突。此外，這種格式還可以提 供對授權用途的理解。
當創建用戶定義的授權時，應該考慮下面的幾個要點：
是否存在某種現有的系統定義的授權，其中包括了合適的特權命令？如果存在，那麼應該考慮使用這 個現有的授權是否符合最少特權原則。
新的授權是否屬於某個現有的用戶定義的授權層次結構、或者它是否為一個新的層次結構中的第一個 授權？
如果該授權需要一個新的層次結構，那麼該結構的格式應該是什麼樣的呢？
在創建授權的時候，應該指定授權 ID 嗎？建議允許 mkauth 命令生成授權 ID。
創建用戶定義的授權
在這個部分中，我們將創建一個名為 operatorPVI 的用戶定義的授權。
稍後，oper1 用戶將使用這個授權來管理特權文件。
我們還將創建一個名為 operator_pvi 的用戶定義的角色，並將 operatorPVI 授權分配給 operator_pvi 角色。
提示：在這個示例中，我們只需要為 oper1 用戶創建一個授權，因此不需要使用層次結構的授權樹。 如果多個用戶需要不同的 PVI 管理授權，那麼創建層次結構的授權（如 ibm.pvi.operator.oper1）可能 更合適一些。
AIX Version 6.1 中包括下面幾個授權管理命令：
mkauth
mkauth 命令可以創建一個新的用戶定義的授權。在創建新的授權之前，所指定的授權名稱中的所有父 元素都必須已經存在於授權數據庫中。
當系統運行於增強的 RBAC 模式時，可以將在授權數據庫中創建的授權立即分配給角色，但是在對內 核安全表進行更新之前，這些授權將不會生效。
rmauth
rmauth 命令用於刪除用戶定義的授權。rmauth 命令將僅刪除授權數據庫中現有的用戶定義的授權。 不能使用這個命令刪除系統定義的授權。當系統運行於增強的 RBAC 模式時，出於安全的考慮，在通過 setkst 命令將授權數據庫發送到內核安全表之前，對該數據庫所做的修改將無法使用。
lsauth
顯示用戶或者系統定義的授權的屬性。
chauth
用於修改現有用戶定義的授權的屬性。系統定義的授權是不能進行修改的。當系統運行於增強的 RBAC 模式時，出於安全的考慮，在沒有通過 setkst 命令將數據庫發送到內核安全表之前，對數據庫所做的修 改將無法使用。
要創建 operatorPVI 用戶定義授權，請遵循下面的操作：
1. 以 root 用戶或者授權管理用戶的身份登錄。
圖 11 顯示 mkauth 命令。在這個示例中，我們允許由系統生成 ID，並使用 dfltmsg 節中的 Operator PVI 管理描述。
圖 11 mkauth 命令
2. 創建 operator_pvi 角色，並分配 operator_pvi 授權。
在創建了 operator_pvi 角色之後，我們可以顯示該角色，並確定為該角色分配哪些授權。在這個示 例中，我們只分配了 operatorPVI 授權。
圖 12 顯示 mkrole 和 lsrole 命令。
圖 12 mkrole 命令
3. 為用戶分配角色。
可以使用 chuser 命令分配 RBAC 角色。
chuser 命令並不能為現有的角色追加新的角色。因為已經為 oper1 用戶分配了現有的角色，所以 chuser 命令的新角色值中需要包括這個現有的角色。
4. 使用 setkst 命令更新 KST。
圖 14 顯示 setkst 命令
如果希望將 operatorPVI 授權用於某些特權命令，那麼現在可以將這些特權命令分配給該授權。因為 operatorPVI 授權將用於特權文件訪問，所以不需要為該授權分配任何特權命令。
特權命令數據庫
這個部分將介紹增強的 RBAC 權限和進程權限集。
權限
權限是一種這樣的機制，它用於在系統調用中為一個進程授予擴充的功能。權限可用於確定命令是否 符合執行某項操作的條件。
權限和授權之間的定義區別在於，權限是與特定的進程相關聯的，而授權則是通過角色與用戶相關聯 的。
權限的概念適用於大部分的內核級構造，因為定義和大部分的檢查都是發生在內核級構造中的。為各 種命令、設備和進程分配相應的權限，這些操作都是在內核之外執行的，然後使用 setkst 命令更新到內 核中。
AIX 將權限定義為位掩碼的各個位，以此執行對特權操作的訪問控制。AIX V6 中附帶了 100 多種權 限，為特權操作提供了非常細粒度的控制。
通過特權命令數據庫，可以為命令調用分配相應的權限；通過特權設備數據庫，可以使用權限來控制 對設備的訪問。
在為系統調用確定訪問權限時，內核將檢查該進程是否具有所需的相關權限位，然後為其授予相應的 權限、或者拒絕執行。
AIX V6 中的權限是預定義的，並且不能夠對其進行修改、刪除或者創建。
權限（與授權一樣）采用了分層結構。所有的權限都以“PV_”前綴開頭，這是權限位的一 種文本表示形式。內核采用層次的方式執行權限檢查。在檢查權限的時候，系統將首先檢查該進程是否具 有所需的最少權限，然後按層次結構繼續進行，檢查是否存在功能更強大的權限。
PV_ROOT 權限是一種特殊的權限，它代表了除 PV_SU_ 之外所有權限的父節點。分配了 PV_ROOT 權限 的進程在執行時就如同已經對其分配了系統中除 PV_SU_ 之外的所有權限。
進程權限集
進程權限集用於動態地約束或者限制特權操作。內核中定義了多個權限集，以便為特權操作提供各種 控制。多個權限集允許操作系統實施動態權限控制，並且允許應用程序實現最少特權原則。
不同的權限通過下面的權限集與進程相關聯。
限制權限集
限制權限集（Limiting Privilege Set，LPS）可以為給定進程定義權限的最大限制或者硬限制。
LPS 定義了最大的權限提升；使用系統中定義的任何接口，進程都不可能獲得比這個值更多的權限。 此時，將進程限制為 LPS 權限。
這也意味著，其余的權限集將始終是 LPS 的子集。
盡管 LPS 是最大限制或者硬限制，並且不允許超過這個限制，但是每個進程都可以減少 LPS 中的權 限。一旦某個進程減少了 LPS 中的權限，那麼這個新的、經過減少的限制將成為新的 LPS，並且不能擴 展或者增加到其原始值。
通過降低 LPS，允許進程根據相關的權限來限定相應的界限。例如，進程可以在執行用戶提供的自定 義程序之前減少 LPS 中的權限。
在缺省情況下，進程的 LPS 中包含系統中可供使用的所有權限。
最大權限集
最大權限集（Maximum Privilege Set，MPS）是某個進程可以使用的所有權限的集合。MPS 可以包括 LPS 中的任何權限，但不能超出 LPS。
MPS 並不是一成不變的，並且僅在 LPS 的限制之內具有硬限制。
因此，在一個進程的生存期內，MPS 的值是可以更改的。
下面提供了一些示例，說明了在什麼情況下可以更改 MPS：
在當前進程執行另一個特權命令，然後獲得相關的附加權限的時候。
如果該進程具有適當的權限，那麼它可以以編程的方式動態地擴展 MPS。
有效權限集
有效權限集（Effective Privilege Set，EPS）是某個進程當前處於活動狀態的權限的列表。EPS 始 終是該進程的 MPS 的子集，並且在執行特權操作時，內核將使用 EPS 進行訪問權限檢查。EPS 並不是一 成不變的，並且可以由進程對其進行控制。EPS 可以與 MPS 相等，但不能超出 MPS。
進程可以執行 EPS 的動態控制，以執行最少特權原則。
可繼承的權限集
可繼承的權限集（Inheritable Privilege Set，EPS）定義了從父進程傳遞到子進程的 MPS 和 EPS 的權限。
IPS 可以包括 LPS 中的任何權限，但是不能超出 LPS。
可以采用下面的方式，在進程中設置 IPS：
如果該進程具有適當的權限，那麼它可以以編程的方式，通過 setppriv() 系統調用來擴展 IPS。
在執行某個特權命令時，將與該命令相關聯的 inheritprivs 屬性中指定的權限分配給 IPS。
使用過的權限集
使用過的權限集（Used Privilege Set，UPS）描述在進程的生存期內曾用於訪問檢查的權限。UPS 可 用於確定該進程所需的權限。
無論內核何時檢查一個進程是否具有給定的權限，它都將會在該權限的 UPS 中存儲一個成功的檢查。
工作負載分區權限集（Workload Partition Privilege Set，WPS）
可以將一個系統 WPAR 配置為限制全局環境中允許的特權操作。可以通過 WPS 對系統 WPAR 中允許的 特權操作進行控制。
全局環境的 root 可以使用 WPS 將有限的權限集分配給 WPAR。可以在 /etc/wpar/secattrs 配置文 件中、或者在啟動 WPAR 期間使用 startwpar 命令指定 WPS。WPAR 中運行的所有進程都將使它們的 LPS 與它們的 WPS 相等。
圖 15 顯示增強的 RABAC 權限集的圖形表示形式。
圖 15 增強的 RBAC 權限集
增強的 RBAC 提供了下面的命令，以便管理各種權限集：
lssectattr
lssecattr 命令用於列出一個或者多個命令、設備或者進程的安全屬性。lssecattr 可用於列出活動 進程的 LPS、MPS、EPS、IPS 和 UPS。
setsecattr
setsecattr 命令可以設置命令、設備或者進程的安全屬性。setsecattr 命令可用於修改活動進程的 LPS、MPS、EPS 和 IPS。不能使用 setsecattr 命令修改 UPS，因為 UPS 是一個只讀屬性。
特權命令
如前所述，AIX 的命令授權通常依賴於 DAC、或者依賴於直接包括於命令代碼中的授權。
增強的 RBAC 利用授權、角色和權限，以提供更細粒度的安全控制方法。
增強的 RBAC 模式提供了一種框架，以便在不需要對系統中可執行文件進行更改、或者對 DAC 權限進 行修改的情況下，執行授權檢查，並通過特權命令數據庫授予相關的權限。
特權命令數據庫允許管理員為命令授予用戶訪問權限和相關權限，否則，它們將不能執行、或者沒有 合適的權限來執行相應的任務。特權命令數據庫用於保存特定命令的授權信息，以及在授權檢查成功的情 況下為進程授予的權限。
當特權命令數據庫存儲在本地時，它位於 /etc/security/privcmd 文件中，並采用命令及其安全屬性 的形式包含相關的信息節。
下面是特權命令數據庫中的一些重要屬性：
accessauths
保護命令執行的訪問授權列表。如果用戶具有該列表中的任何一個授權，那麼將允許其執行相應的命 令，並且執行其中包含的某些或者所有特權操作。
innateprivs
固有權限是在調用者成功地進行了訪問授權檢查的情況下，分配給進程的權限。
authprivs
授權權限是在調用者具有相關授權的情況下，分配給進程的附加權限。這個屬性為命令提供了更細粒 度的控制，它允許一組受限的用戶執行附加的特權操作。
inheritprivs
可繼承的權限是該進程將傳遞給其子進程的權限。
secflags
安全標志的列表。
當增強的 RBAC 模式系統中的用戶嘗試執行某個命令時，首先將在特權命令數據庫中查找該命令。
如果數據庫中存在該命令，那麼將根據與用戶會話相關聯的授權，以及被調用命令的 accessauths 屬 性值執行檢查。如果該會話具有所列出的某個授權，那麼將允許這個用戶執行該命令，而無論這個用戶是 否通過該命令的 DAC 執行檢查。
圖 16 顯示增強的 RBAC 命令執行過程的圖形表示形式。
圖 16 增強的 RBAC 命令執行
如果一個命令包含於特權命令數據庫中，那麼它將作為一個 RBAC 特權命令。如果一個程序使用了 setuid，並且該程序沒有在特權命令數據庫中列出，那麼它仍然可能分類為特權的，但不能稱為 RBAC 特 權命令。
如果一個命令在特權命令數據庫中沒有任何條目，那麼它不是 RBAC 特權命令，並且對它的訪問由 DAC 和該命令本身來執行。
如果一個命令包含於特權命令數據庫中，但是調用者的會話不具有允許執行該命令的授權，那麼在 DAC 和 UID/GUID 檢查成功的情況下，將仍然允許執行該命令。
特權文件數據庫
在這個部分中，我們將介紹特權文件數據庫和 pvi 命令。
使用 DAC 的特權文件管理
通常在 AIX 5L 中，許多系統配置文件都由 root 用戶所有，並且利用 DAC 文件權限設置來防止一般 用戶對系統配置文件進行修改。
某些系統配置文件使用了命令接口，以便允許對其進行修改和管理。/etc/inittab 文件使用了 DAC， 以便只允許 root 用戶對該文件進行寫訪問。如果需要由 root 用戶以外的其他用戶對該文件進行更新， 那麼可以使用 RBAC 創建一個角色/授權，以便允許執行 inittab 管理命令集，包括由 root 用戶以外的 其他用戶執行的 chitab、rmitab、lsitab 和 mkitab。
在 AIX 5L 中，並不是所有的系統配置文件都提供了命令接口以實現對文件的修改。需要為這些文件 提供一種工具，允許具有合適授權的管理員直接編輯和保存文件（否則，他們將不能訪問該文件）。
使用 RBAC 的特權文件管理
特權文件數據庫中包含被管理員定義為需要特權授權的文件的列表。當在本地進行存儲時，特權文件 數據庫位於 /etc/security/privfiles 文件中。特權文件數據庫將特權文件映射為對其進行查看或修改 所需的授權。
pvi 命令使用特權文件數據庫來確定任何特權文件的名稱和授權模式。
特權文件可能包括不使用單獨的命令接口的任何系統配置文件、以及管理員希望對其進行訪問限制的 其他文件。
特權文件數據庫使用 RBAC 授權作為一種授權或者限制文件訪問的方法。
特權文件數據庫中所包含的文件應該與相同的 tvi（受信任的 vi，trusted vi）命令一致，並且對 tvi 或者 vi 命令來說，應該是可讀的文件。
注意事項：在將文件添加到特權文件數據庫之前，該文件必須已經存在。不能使用 pvi 命令創建一個 新的文件。
特權文件數據庫的限制
特權文件數據庫執行下面的限制：
tvi 命令現有的所有限制都保留於 pvi 命令中。
系統必須運行於增強的 RBAC 模式中。
在通過特權文件數據庫對其進行管理時，該文件必須已經存在。不能使用 pvi 命令創建文件。
只有特權文件數據庫中所包含的文件才可以由 pvi 命令進行編輯。
pvi 命令一次只允許打開一個文件。
pvi 命令無法使用與文件打開時不同的名稱保存該文件。
不能使用 pvi 命令來編輯特權文件數據庫。
使用 pvi 命令只能打開常規文件。不能使用 pvi 命令打開文件鏈接。
pvi 命令不支持用戶定義的宏。
特權文件數據庫僅支持讀授權 (readauth) 和寫授權 (writeauth)。
在授予 writeauth 權限時，其中隱含了 readauth，但是該授權將不會更新到 /etc/security/privfiles 文件的 readauth 節中。
向特權文件數據庫添加一個文件
安全控制人員請求我們允許給予 oper1 用戶對 /etc/hosts 文件的讀/寫訪問權限。我們將創建一個 用戶定義的角色和授權，然後將 /etc/hosts 文件添加到特權文件數據庫，從而允許 oper1 用戶對 /etc/hosts 文件進行讀寫操作。
/etc/hosts 文件具有相應的 DAC 權限，允許 oper1 用戶和 root 用戶以外的其他所有用戶或者 system 組的成員對其進行只讀訪問。
圖 17 /etc/hosts 文件的 DAC 權限
要向特權文件數據庫中添加一個文件，請執行下面的步驟：
1. 創建或者確定將用於特權文件訪問的授權和角色。
特權文件數據庫使用 RBAC 授權，以便對文件的讀寫訪問控制進行身份驗證。
對於要添加到特權文件數據庫中的文件，管理員必須了解以下內容：
文件名稱。
讀授權 (readauth) 的 RBAC 授權。如果指定了 writeauth，readauth 則不是強制的。readauth 可 以指定為一個授權列表。
寫授權 (writeauth) 的 RBAC 授權，如果需要的話。writeauth 可以指定為一個授權列表。
在這個示例中，我們將使用先前在“用戶定義的角色”中創建的 operatorPVI 授權和 operator_pvi 角色。
2. 使用 setsecattr 命令，我們將 /etc/hosts 文件添加到特權文件數據庫。
我們將為 operatorPVI 授權定義對 /etc/hosts 文件的寫訪問權限。
在圖 30 中，我們使用 setsecattr 命令將 /etc/hosts 文件添加到特權文件數據庫中，並允許授予 operatorPVI 對該文件的寫訪問權限。對 /etc/hosts 文件的寫訪問權限 (writeauth) 還支持對該文件 的讀訪問權限 (readauth)。
圖 18 setesattr 命令
3. 使用 setkst 命令更新內核安全表。
如果 oper1 用戶試圖在不更新 KST 的情況下使用 pvi 命令，那麼 pvi 命令將會失敗，因為 KST 中 的安全檢查將無法找到 oper1 用戶的 readauth 或者 writeauth 的有效條目。
圖 19 顯示 oper1 用戶在更新 KST 之前執行 pvi 命令。
圖 19 在更新了 KST 的情況下使用 pvi 命令訪問 /etc/hosts 文件
4. oper1 用戶現在可以使用 pvi 命令對 /etc/hosts 文件進行讀寫操作。
如果 oper1 用戶試圖使用 vi 命令修改和保存 /etc/hosts 文件，那麼將使用 /etc/hosts DAC 文件 權限以確定 oper1 用戶是否具有適當的權限，以保存對該文件的更改。
oper1 用戶不具有對 /etc/hosts 文件進行寫訪問的 DAC 權限，因此保存 /etc/hosts 文件的嘗試將 無法成功。
圖 20 顯示 oper1 用戶使用 vi 命令編輯 /etc/hosts 文件。可以查看該文件，但不能保存數據，因 為 DAC 文件權限只允許用戶 oper1 進行讀訪問。
圖 20 用戶 oper1 使用 vi 命令編輯 /etc/hosts 文件
當使用 pvi 命令編輯 /etc/hosts 文件的時候，其結果是不同的。
當使用 pvi 命令的時候，用戶 oper1 可以修改並保存 /etc/hosts 文件。
圖 21 顯示 oper1 用戶使用 pvi 命令編輯 /etc/hosts 文件。可以查看、修改和保存該文件。即使 DAC 文件
權限只允許用戶 oper1 進行讀訪問。
圖 21 用戶 oper1 使用 pvi 命令編輯 /etc/hosts 文件
特權設備數據庫
這個部分將討論特權設備數據庫。
使用 RBAC 的特權設備管理
從概念上看，特權設備數據庫與特權文件數據庫非常類似，但特權設備數據庫用於控制對設備的訪問 ，而不是控制對文件的訪問。
與通過傳統的設備訪問控制方法所管理的數據庫相比，特權設備數據庫可用於為數據庫提供更好的訪 問控制。
當在本地存儲該數據庫時，它包含於 /etc/security/privdev 文件中。
特權設備數據庫采用下面的屬性，以存儲對設備進行讀寫操作的特權信息：
readprivs
列出允許從設備進行讀操作的權限。
在提出讀請求以打開某個特權設備時，只有在 readprivs 中指定某個權限存在於該進程的有效權限集 (EPS) 中時，才允許打開設備。
writeprivs
列出允許對設備進行寫操作的權限。
在提出寫請求以打開某個特權設備時，只有在 writeprivs 中指定某個權限存在於該進程的有效權限 集 (EPS) 中時，才允許打開設備。
可以使用 lssecattr 和 setsecattr 命令，將一個設備包括到特權設備數據庫中。
在將設備包括到特權設備數據庫中之前，必須對需要訪問該設備的命令和應用程序進行全面的分析， 以確保指定了適當的權限。
