簡介：在本系列文章中，我們將向您陸續介紹並和您一起討論基於角色的訪問控制（Role Based Access Control）的相關內容。作為 AIX 6 的安全新特性，RBAC 為用戶提供了細顆粒度的，更加靈活的 安全管理方法。本文是摘自 IBM 紅皮書《AIX V6 Advanced Security Features Introduction and Configuration》。
AIX V6 和基於角色的訪問控制 (RBAC)
AIX V6 引入了增強 RBAC，即向一個或者多個普通用戶帳戶委派角色和授權的方法。
RBAC 允許系統管理員將某些任務委派給普通用戶，而傳統的做法是，這些任務由 root 用戶，或者通 過 setuid/setgid 執行。
RBAC 的優點之一是，通過限制分配給某個命令的權限（僅為命令分配執行其任務所必需的權限），可 以盡可能地減少 setuid/setgid 程序的使用。
AIX V6 中沒有提供遺留或者增強模式 RBAC 的特定安裝包。大多數增強 RBAC 命令都包含在 bos.rte.security 文件集中。
下面的部分將對增強 RBAC 中所包括的組件進行介紹和深入地討論。
傳統的 AIX 管理方法
這裡，我們將介紹傳統的 AIX 管理方法，以及用於該目的的一些工具。
超級用戶管理帳戶
在 AIX 操作系統中，傳統的特權管理方法依賴於名為 root 的單個系統管理員帳戶。我們將 root 帳 戶作為超級用戶，這是因為 root 用戶帳戶有權執行 AIX 系統中所有特權的系統管理任務。通常將 root 用戶的用戶標識/uid 指定為 0。
僅依賴單個超級用戶來完成系統管理中各方面的操作，將在管理職責分離方面產生一些問題。盡管在 某些業務環境中，可以僅使用一個管理帳戶，但很多環境都需要多個管理員，其中各個管理員負責執行不 同的任務。
如果僅使用一個管理帳戶，那麼就可能需要在兩個或者更多系統管理員之間共享使用超級用戶的角色 。在某些環境中，需要將所有特權的系統管理任務集中於一個單獨的個體，那麼這種共享的管理方法可能 會破壞其中的業務審核指導原則。
共享超級用戶角色的一種替代方法是，創建與 root 用戶具有相同 UID 的另一個用戶。
從安全的角度來說，無論采用這兩種方式中的任何一種，都可能產生各種各樣的問題，因為向每個管 理員授予了系統的全部控制權限。沒有辦法限制任何給定的管理員所能夠執行的操作。因為 root 用戶是 權限最高的用戶，所以該用戶可能執行未經授權的操作，還可以刪除對這些活動的任何審核信息，因此要 對其管理操作進行跟蹤，幾乎是不可能的。
自主訪問控制 (DAC)
自主訪問控制 (DAC) 是一些安全方面的特性，它們受到某個文件或者目錄的所有者的控制。
在 AIX 中，可以使用所有者/組/其他用戶和讀/寫/執行的傳統文件對象權限位的方法來實現 DAC。
通過使用文件對象權限位，每個用戶可以確定另一個用戶或者組是否需要訪問某個特定文件對象中的 數據。DAC 通常需要了解相關的標准，並相應地授予權限或者拒絕訪問。這種類型的訪問建立在用戶所屬 的 UID 和 GID 的基礎之上。所有的文件系統對象都具有相關的權限，以描述所有者、組和其他用戶的訪 問權限。
注意事項：使用 DAC ，可以將某個用戶 ID 指定為一個可執行文件的所有者，以便只有該用戶可以運 行這個文件。如果這個用戶離開了公司，那麼系統管理員就必須修改該文件的 DAC ，否則任何其他用戶 都無法運行該文件。在通過組 ID 使用 DAC 時，同樣也會出現這種情況。
在示例 1 中，我們可以看到 oper1 用戶的 home 目錄中所包含的文件對象。文件 MyBankBallance.txt 是關於如何使用 DAC 來限制某些用戶或者組對文件進行訪問的示例。
示例 1 用戶“oper1”的文件對象權限位 DAC
oper1@trinity:/home/oper1# ls -ltra total 48
-rwxr----- 1 oper1 staff 254 Apr 18 07:34 .profile drwxr-xr-x 10 bin bin 256 Apr 18 07:35
-rw-r--r-- 1 oper1 staff 553 Apr 19 23:24 smit.transaction
-rw-r--r-- 1 oper1 staff 418 Apr 19 23:24 smit.script
-rw-r--r-- 1 oper1 staff 1079 Apr 19 23:24 smit.log drwxr-xr-x 2 oper1 staff 256 Apr 20
-rw------- 1 oper1 staff 79 Apr 20 01:59 MyBankBallance.txt
-rw------- 1 oper1 staff 390 Apr 20 02:00 .sh_history oper1@trinity:/home/oper1#
使用用戶 ID (UID) 和組 ID (GID) 進行授權
如前所述，DAC 能夠基於讀、寫或者執行權限，限制對文件對象的訪問。盡管通過使用 AIX 文件權限 和所有權，DAC 提供了某些控制粒度，但是 DAC 無法保護對文件對象的權限或所有權的惡意或者意外修 改。如果某個文件對象是一個可執行程序，要進一步進行限制的方法之一是使用 UID/GID 訪問控制，僅 允許具有合適的 UID/GID 的用戶對其進行訪問。
如果一個可執行程序中包含 UID/GID 檢查，那麼只有在進程 UID/GID 與該可執行程序中所包括的嵌 入 UID/GID 相匹配的時候，該程序才能夠成功地執行。
在下面的示例中，我們說明了以下內容：
1. 修改一個特權文件對象的 DAC 設置，以允許所有的用戶對其進行操作
2. 嘗試使用非 root 用戶、或者 shutdown 組之外的用戶執行 shutdown 命令。
shutdown 命令是 root 用戶所擁有的 Shell 腳本，並且 shutdown 組擁有讀和執行權限。shutdown Shell 腳本包括用以檢查 UID/GID 是否為 root:shutdown 的 UID/GID 檢查機制。如果 UID/GID 不符合 ，那麼 shutdown Shell 腳本將調用 exec_shutdown 可執行程序。
為了使系統中的所有用戶都能夠執行 shutdown 命令，我們必須修改其權限，以允許 shutdown 組之 外的用戶進行讀和執行操作。
在示例 2 中，我們修改了 shutdown 和 exec_shutdown 命令，以允許系統中的所有用戶都能夠執行 這兩個命令。
示例 2 修改 DAC 權限以允許執行
root@trinity:/root# ls -ltra /usr/sbin/shutdown
-r-xr-x--- 1 root shutdown 42939 Apr 17 10:26 /usr/sbin/shutdown
root@trinity:/root# ls -ltra /usr/sbin/exec_shutdown
-r-xr-x--- 1 root shutdown 2694 Apr 17 10:26 /usr/sbin/exec_shutdown
root@trinity:/root# chmod 555 /usr/sbin/shutdown
root@trinity:/root# chmod 555 /usr/sbin/exec_shutdown
root@trinity:/root# ls -ltr /usr/sbin/shutdown
-r-xr-xr-x 1 root shutdown 42939 Apr 17 10:26 /usr/sbin/shutdown
root@trinity:/root# ls -ltra /usr/sbin/exec_shutdown
-r-xr-xr-x 1 root shutdown 2694 Apr 17 10:26 /usr/sbin/exec_shutdown
root@trinity:/root#
現在，我們已經修改了 shutdown 和 exec_shutdown 命令的 DAC 權限，以允許系統中的任何用戶都 能夠執行這兩個命令，我們將使用用戶 oper1 進行登錄，並執行 shutdown 命令。用戶 oper1 具有 UID 208，並且屬於 staff 組。
在示例 3 中，我們將使用用戶 oper1 執行 shutdown 命令。
示例 3 使用用戶 oper1 執行 shutdown 命令
oper1@trinity:/home/oper1# id uid=208(oper1) gid=1(staff)
oper1@trinity:/home/oper1# ls -ltra /usr/sbin/shutdown
-r-xr-xr-x 1 root shutdown 42939 Apr 17 10:26 /usr/sbin/shutdown
oper1@trinity:/home/oper1# ls -ltra /usr/sbin/exec_shutdown
-r-xr-xr-x 1 root shutdown 2694 Apr 17 10:26 /usr/sbin/exec_shutdown
oper1@trinity:/home/oper1# shutdown -F
oper1@trinity:/home/oper1#
雖然執行了 shutdown 命令，但是並沒有執行系統關閉的任務，該命令在沒有執行預期的系統關閉操 作的情況下就退出了。這是因為 exec_shutdown 可執行程序還將檢查 UID/GID 是否為 root:shutdown。 如果 UID/GID 不能匹配 exec_shutdown 可執行程序中所編碼的值，那麼該程序將會退出。
在 AIX 5L 中，UID/GID 訪問檢查的這個示例並沒有得到廣泛使用。並非所有關鍵的命令都已經按照 這種方式進行了編碼，以確保不管 DAC 的設置如何，這些命令只有在使用特權 UID/GID 的時候才能夠執 行相應的操作。
在圖1 中，我們概括了 shutdown 命令所使用的 UID/GID 流程，以確定 oper1 用戶是否具有執行該 命令和 shutdown 程序的適當授權。
圖 1 UID/GID 授權控制的說明
通過設置用戶標識 (setuid) 提升權限
在 AIX 中，傳統的訪問控制方法是通過使用與進程相關聯的用戶標識來實現的，以便根據可執行程序 的 DAC 權限來確定訪問控制。然而，通常允許 ID 為 0 的 root 用戶繞過權限檢查，因此對於以 root 用戶的身份所執行的進程，可以順利地通過系統中的任何訪問檢查，並執行任何所需的操作。在使用 setuid 應用程序的時候，這一點就成為了一個安全問題。
setuid 的概念允許命令以調用該命令的用戶以外的另一個用戶標識來執行。當普通用戶需要完成特權 任務的時候，setuid 可能是非常有必要的。passwd 命令就是這種情況的一個示例。/etc/passwd 文件使 用了 DAC 權限，限制為只有 root 用戶具有對該文件的讀/寫訪問權限。因為除了 root 用戶之外的任何 用戶都不能對存儲用戶密碼的文件進行訪問，所以普通用戶需要具有附加的權限才能更改他們的密碼。
出於這個原因，可以將 passwd 命令的用戶標識設置為 root 用戶。當以 root 用戶之外的其他用戶 調用 passwd 命令的時候，對於操作系統來說，就好像 root 用戶正在訪問該文件，並且該訪問是允許的 。
盡管 setuid 概念允許實現一些所需的訪問控制功能，但它具有某種固有的安全風險。因為 setuid 程序可以在 root 用戶的上下文中有效地執行，如果在某個程序（正使用相應的 setuid 位執行的程序） 退出之前，攻擊者成功地接管了該程序，那麼該攻擊者將擁有 root 用戶的所有權限。然後，該攻擊者就 能夠繞過所有的訪問檢查，因為該攻擊者可以保持有效的 root 用戶權限，並且能夠執行 root 用戶可以 執行的所有操作。
對於特權命令的執行，一種更安全的解決方案是，只為程序分配 root 用戶權限的一個子集，即遵循 最少權限原則，從而減少相應的威脅。
最少權限原則是一種保障安全的方法，它僅為一個進程或者個人授予執行某項特定任務所需的職權或 者權限。
該用戶對其他文件或者命令的訪問權限，將根據需要進行限制。
RBAC 的介紹
在這個部分中，我們將對 RBAC 中所包括的組件進行介紹。
遺留模式與增強模式 RBAC 的對比
在 AIX V4.2 中就引入了 RBAC 的實現，但具有一定的局限性。從 AIX Version 6.1 開始，所包含的 RBAC 的新實現提供了很好的細粒度機制，通過這種機制可以更好地控制各種管理任務，與特權命令執行 控制相比，為管理員提供了一種更加精確、並且可以自定義的方法。
因為 RBAC 的這兩種實現在其操作范圍和功能方面具有顯著的區別，所以這兩種 RBAC 實現將使用下 面的術語來描述它們的相關實現：
遺留 RBAC 模式——AIX V 4.2.1 中引入的 AIX 角色的歷史行為
增強 RBAC 模式
——AIX Version 6.1 中所引入的新實現
在 AIX V6 中，同時支持這兩種操作模式，然而，增強模式 RBAC 在最近安裝的系統中是缺省啟用的 。
遺留模式 RBAC
在 AIX V4.2.1 發行的時候，AIX 安全基礎設施就開始提供有限的 RBAC 功能。現在將這種功能稱為 遺留模式 RBAC，它允許 root 用戶之外的其他用戶執行某些特權的系統管理任務。在遺留 RBAC 實現中 ，當 root 用戶之外的其他某個用戶調用一個給定的管理命令時，所執行的命令中的代碼將確定是否已經 向該用戶分配了具有所需授權的角色。如果該用戶是經過授權的，那麼將繼續執行；如果該用戶沒有經過 授權，那麼該命令的執行將會失敗，並顯示一個錯誤。為了使經過授權的調用者具有適當的權限以完成相 應的操作，遺留 RBAC 通常需要將由授權控制的命令的用戶標識設置為 root 用戶。
遺留 RBAC 實現還引入了一組預定義的授權，它們可用於確定對一些管理命令的訪問權限。管理員可 以擴展這些預定義的授權。此外，還提供了用於創建角色、為角色分配授權，以及為用戶分配角色的管理 命令和接口的框架。
盡管遺留 RBAC 實現提供了對管理職責進行部分劃分的能力，但是它也具有下列局限性：
要使得命令/應用程序支持 RBAC，框架需要對其進行相應的更改。
預定義授權的粒度不如增強模式 RBAC。
為了執行某個命令，用戶通常需要作為某個組中的成員，並且擁有具有給定授權的角色。
很難實現真正的職責分離。如果為一個用戶分配了多種角色，那麼所分配的所有角色始終都是活動的 。無法僅激活分配給該用戶的某個角色，而同時不激活為該用戶分配的其他所有角色。
操作系統中沒有采用最少權限原則。通常，必須將特權命令的用戶標識設置為 root 用戶。
盡管將繼續支持遺留 RBAC，但我們強烈建議管理員盡量使用增強 RBAC。增強 RBAC 提供了粒度更細 的授權控制，並且減少了對 setuid 程序的依賴。
增強模式 RBAC
從 AIX V6 開始，提供了 RBAC 的進一步實現。
這種增強模式 RBAC 允許將需要一些管理權限以執行某些操作的應用程序集成到增強 RBAC 基礎設施 所包括的新功能中。
增強 RBAC 集成選項使用細粒度的權限和授權，並允許管理員將系統中的任何命令配置為特權命令。 對於從 AIX V6 開始的所有安裝，在缺省情況下都會安裝並啟用增強 RBAC 的各種特性。
通過增強 RBAC 安全數據庫，增強 RBAC 允許管理員提供自定義的授權、角色、特權命令、設備和文 件的集合。
對於增強 RBAC，其安全數據庫可以存儲於本地文件系統中，也可以通過 LDAP 對其進行遠程管理。
增強 RBAC 由下面的安全數據庫文件組成：
授權數據庫
角色數據庫
特權命令數據庫
特權設備數據庫
特權文件數據庫
增強 RBAC 安全數據庫文件都是文本文件，並且不需要在 AIX V6 系統中安裝附加的數據庫子系統。
在本章稍後的部分中，將對增強 RBAC 數據庫進行更深入討論。
增強 RBAC 模式引入了一種新的授權命名約定，它允許創建授權的層次結構。增強 RBAC 包括一組細 粒度的、系統定義的授權，並允許管理員根據需要創建更多的用戶定義的授權。
注意：在發布的時候，增強 RBAC 可以通過命令行或者 SMIT 工具來進行管理。 WebSM 中不包括對增 強 RBAC 的支持。
授權
在增強 RBAC 中，授權是與安全相關功能或者命令相關聯的文本字符串。授權提供了一種機制，以便 為用戶授予相應的權限以執行某些特權操作，並對不同類別的用戶提供不同的功能級別。通常先將授權分 配給角色，然後再將角色分配給用戶。
當執行由某個授權所管理的命令時，僅在調用該命令的用戶具有所需授權的情況下，才能夠為其授予 訪問權限。出於這個原因，可以將授權看作解鎖一個或者多個命令的鑰匙。
角色
對於增強 RBAC，角色的行為得到了進一步發展，以便提供職責功能的分離。增強 RBAC 還為 AIX 引 入了角色會話(role sessions)的概念。一個角色會話定義為一個進程，該進程具有與其相關聯的一個或 者多個角色。增強 RBAC 允許用戶為他們所分配的任何角色選擇激活一個角色會話。在缺省情況下，登錄 時不激活任何用戶角色，這使用戶能夠激活當前活動所需的角色。
角色得到了進一步增強，以支持用戶在激活角色之前必須進行身份驗證的需求。這種身份驗證需要在 激活該用戶所分配的任何角色之前，對用戶的登錄密碼進行身份驗證。
這種授權增強有助於防止攻擊者接管用戶會話，因為如果攻擊者想要激活該用戶的角色，仍然需要通 過輸入該用戶的登錄密碼來進行身份驗證。
權限
特權命令數據庫的引入允許實現最少權限原則。最少權限原則是一種為用戶分配完成某項任務/命令/ 進程所需的最少權限的方法。
增強 RBAC 增加了系統中的權限粒度，允許為某個命令授予顯式權限，並執行需要由授權進行管理的 命令。
有了特權命令數據庫之後，就不再需要使用 setuid 和 setgid 程序，它允許管理員僅分配成功執行 命令所需的權限，而不需要更改實際命令的代碼。
特權設備數據庫允許對由權限控制的設備進行讀寫訪問。
特權文件數據庫將允許未經權限的用戶根據授權對受限的文件進行讀寫訪問。
特權命令數據庫、特權命令和特權文件數據庫提高了系統管理任務的粒度，可以將這些任務分配給一 些並不具備特權的用戶。
內核安全表
增強 RBAC 提供了一種機制，以收集和驗證增強 RBAC 安全數據庫中的信息，然後將這些信息發送到 指定為內核安全表（Kernel Security Tables，KST）的內核區域。KST 中的數據可以確定系統的安全策 略。直到信息經過驗證、並更新到 KST（也稱為內核級）中之後，才能將文件或者 LDAP（也稱為用戶級 ）RBAC 安全數據庫中經過修改的條目用於安全決策。
可以使用 setkst 命令更新 KST。可以使用 lskst 命令顯示 KST 的內容。
使用 LDAP 提供遠程數據庫支持
在包括許多服務器的環境中，在一個集中的位置維護 RBAC 安全數據庫，可能更為有效。在需要跨所 有的系統實現和加強公共安全策略的企業環境中，情況也是如此。
當控制安全策略的 RBAC 安全數據庫獨立地存儲於各個系統中時，安全策略的管理就成為了指定管理 員的負擔。
在 AIX V6 中，增強 RBAC 模式允許在 LDAP 中存儲增強 RBAC 安全數據庫。這允許為 LDAP 環境中 所有的系統集中地管理安全策略。
AIX V6 中支持將所有的增強 RBAC 安全數據庫放置於 LDAP 中，具體包括以下數據庫：
授權數據庫
角色數據庫
特權命令數據庫
特權設備數據庫
特權文件數據庫
局限性：存儲在 LDAP 中的授權數據庫將僅包含用戶定義的授權。系統定義的授權無法存儲在 LDAP 中，它們將保存在各個客戶端系統的本地。
AIX V6 中所提供的各種實用工具允許管理員進行以下操作：
將本地 RBAC 安全數據庫的數據導出到 LDAP。
配置 AIX V6 客戶端，以便使用 LDAP 中的 RBAC 數據。
控制 RBAC 安全數據庫數據的域查找。
管理來自客戶端系統的 RBAC 安全數據庫 LDAP 數據。
表 1 比較 RBAC 各種模式中可用的特性。
特性 遺留 RBAC 模式 增強 RBAC 模式 選擇性的角色激活 在缺省情況下，所有的用戶角色都是活動的。 在缺省情況下，所有的角色都是非活動的。可以使用 swrole 命令來使用相應的角色。 default_roles 屬性 否 是 swrole 命令 否 是 角色管理命令 是 是 授權管理命令 是 是 授權層次結構 否 支持授權層次結構的概念 授權檢查 僅當命令需要在執行時檢查授權的情況下強制進行。 在執行時，通過特權命令數據庫或者通過命令檢查授權強制進行。 細粒度權限 是 是 pvi 命令 否 是 內核安全表 否 是 RBAC 數據庫位置 本地文件 本地文件或者 LDAP表 2 顯示了增強 RBAC 的大小限制。
描述 局限性 角色名稱的最大長度 63 個可打印的字符 每個會話可以擁有的最大角色數目 8 授權名稱的最大長度 63 個可打印的字符 授權層次結構中所允許的最大層次數目（包括頂層的父節點） 9 每個命令可以擁有的訪問授權的最大數目 8 每個命令可以擁有的最大授權特權集合 8配置 RBAC
在這個部分中，我們將簡要介紹如何在 AIX V6 中安裝和配置 RBAC。
配置 RBAC 操作模式
“RBAC 的介紹”部分中所描述的，在安裝 AIX V6 時，在缺省情況下將以增強模式激活 RBAC。要確定 RBAC 的當前運行模式，可以顯示 sys0 資源的 enhanced_RBAC 模式。
在示例 4 中，我們使用 lsattr 命令和 sys0 資源顯示了當前活動的 RBAC 模式。
示例 4 顯示 RBAC 模式
root@trinity:/root# lsattr -El sys0 -a enhanced_RBAC
enhanced_RBAC true Enhanced RBAC Mode True root@trinity:/root#
注意：在 WPAR 環境中，只能夠從全局系統對系統的 RBAC 模式進行配置，並且系統的 RBAC 模式將 按照統一的方式影響全局系統以及系統中的所有 WPAR 。
切換到遺留 RBAC 模式
如果您希望切換到遺留 RBAC 模式，那麼可以通過將 enhanced_RBAC 屬性設置為 false 來完成這項 任務。更改 RBAC 模式需要重新啟動服務器。
在示例 5 中，我們使用了 chdev 命令，以便將 RBAC 模式從增強模式更改為遺留模式。
示例 5 將 RBAC 模式從增強模式更改為遺留模式
root@trinity:/root# lsattr -El sys0 -a enhanced_RBAC
enhanced_RBAC true Enhanced RBAC Mode True
root@trinity:/root# chdev -l sys0 -a enhanced_RBAC=false sys0 changed
root@trinity:/root# lsattr -El sys0 -a enhanced_RBAC
enhanced_RBAC false Enhanced RBAC Mode True
root@trinity:/root# shutdown -Fr
root 用戶和增強 RBAC
當采用增強 RBAC 模式使用 RBAC 的時候，root 用戶將繼續生效（與以前的 AIX 5L 發行版中一樣） ，並且可以保持其作為超級用戶帳戶的傳統角色。
增強 RBAC 具有一個特性，即能夠禁用 root 用戶帳戶，並通過一個或者多個用戶帳戶，執行所有的 特權管理和命令。
RBAC 中的預定義角色
在這個部分中，我們將討論如何為用戶添加一個預定義的角色。
隨著 AIX V6 中增強 RBAC 的發布，在 RBAC 的缺省配置中包括了三個預定義的角色和幾個子角色。
這三個預定義角色分別是：
ISSO：信息系統安全官 (Information System Security Officer)
ISSO 角色負責創建和分配角色，因而是系統中功能最強大的用戶定義角色。ISSO 的職責包括：
建立和維護安全策略
設置用戶密碼
網絡配置
設備管理
SA：系統管理員 (Systems Administrator)
SA 角色提供了日常的管理功能，並負責以下事項：
用戶管理（除了密碼設置以外）
文件系統管理
軟件安裝更新
網絡守護進程管理
設備分配
SO：系統操作員 (System Operator)
SO 角色提供了日常操作所需的功能，並負責以下事項：
系統關閉和重新啟動
文件系統備份、恢復和配額
系統錯誤日志記錄、跟蹤和統計
工作負載管理
這些預定義角色中的每一種角色都具有預配置的授權定義，並且如果需要的話，可以進行進一步自定 義。
注意： Trusted AIX 將使用 ISSO 、 SA 和 SO 角色。如果您的環境中包括 Trusted AIX ，那麼您 可能會希望通過使用用戶定義的角色來自定義您的 RBAC 環境。
為用戶添加一個角色
正如在本部分中前面所討論的，SO 預定義角色包括用以執行 reboot 和 shutdown 命令的授權。
如果我們不知道某個預定義角色是否包括 shutdown 和 reboot 命令，那麼可以執行如下的過程：
1. 確定需要執行的特權命令。在這個示例中，需要執行的是 shutdown 和 reboot 命令。
將完全限定的特權命令添加到 smitty 菜單的條目字段區域，並選擇 Enter 鍵。
圖 2 顯示了 smit setsecattr_cmdmod 快速路徑。
2. 確定該特權命令是否包括在授權中。如果預定義的授權中沒有包括該命令，那麼可能需要定義一個 用戶定義的授權。
smit setsecattr_cmdmod 命令顯示了 /usr/sbin/exec_shutdown 命令的授權為 aix.system.boot.shutdown。
使用相同的方法，我們可以確定 aix.system.boot.reboot 授權中定義了 /usr/sbin/reboot 命令。
此外，可以使用 lssecattr 命令，在不調用 smitty 菜單的情況下，獲取相關的信息。
圖 3 顯示了 lssecattr 命令
圖 4 顯示了 exec_shutdown 命令和 smitty setsecattr_cmdmod
3. 確定是否存在某個合適的角色包括了該授權。如果預定義的角色中沒有包括合適的角色，那麼可能 需要定義一個用戶定義的角色。
lsrole 命令可用於列出各種已定義的角色。可以組合使用 lsrole 和 grep 命令，以確定是否為角色 分配了某個授權。
圖 5 顯示了 SO 角色包含幾種授權，其中包括 aix.system.boot.reboot 和 aix.system.boot.shutdown。
圖 5 lsrole 命令
另一種選擇是，使用 lsauth 命令和角色屬性，以顯示將某個授權所分配到的角色。
lsauth 命令可以與“*”通配符一起使用。可以在名稱的末尾使用通配符，以列出整個層 次結構。在通配符之前指定的整個字符串必須是一個有效的授權名稱。
圖 6 顯示了與角色屬性一起使用的 lsauth 命令
通過使用 lsrole 和 lsauth 命令的組合，我們可以確定授權所分配到的一個角色或者多個角色、以 及分配給角色的授權。
4. 將角色分配給用戶。
可以使用 chuser 命令來分配 RBAC 角色。
圖 7 顯示了在將 so 角色分配給 oper1 用戶之前，lsuser 命令的輸出。當前沒有為 oper1 用戶分 配任何角色，
因此角色值為空。
圖 7 對沒有分配任何角色的 oper1 執行 lsuser
chuser 命令並不會為現有的角色追加新的角色。如果已經為 oper1 用戶分配了一些現有的角色，那 麼需要在 chuser 命令的新角色值中包含這些現有的角色。
圖 8 顯示了使用 chuser 命令為 oper1 用戶添加 so 角色的操作
5. 激活角色。
在缺省情況下，在用戶登錄系統並使用 swrole 命令之前，所有的角色都是非活動的。如果 oper1 用 戶要在不激活 so 角色的情況下執行 shutdown 命令，那麼 shutdown 命令將嘗試以 oper1 用戶來進行 執行。因為在激活所分配的某個角色之前，oper1 用戶並不具有任何特殊權限，所以 shutdown 命令將不 能成功地完成。
通過激活 so 角色，oper1 用戶將獲得為 so 角色授予的訪問控制權限。對於由 oper1 用戶（包括在 so 角色所包含的某個授權中）所執行的任何命令，將使用執行該命令所需的權限來進行執行。
在圖 9 中，我們以 oper1 用戶的身份進行登錄，並執行 rolelist -a 命令，以顯示分配給 oper1 的角色和授權。
然後，我們執行 rolelist -a 命令，以顯示有效的角色。可以將這些有效的角色看作當前處於活動狀 態、並且可供 oper1 用戶使用的角色。
因為此時不存在任何處於活動狀態的有效角色，所以由 oper1 用戶執行的任何命令在執行時不使用任 何附加權限，這樣一來，shutdown -Fr 命令將會退出，而無法執行 shutdown 程序。
圖 9 rolelist 命令
要激活一個角色，可以使用 swrole 命令。
swrole 命令將啟動一個新的 Shell，這個 Shell 需要用戶使用他們的密碼進行身份驗證。
在對密碼進行了身份驗證之後，將激活該角色，並且將該角色所定義的授權中所包括的命令作為特權 命令進行執行。
在圖 10 中，我們執行了 swrole 命令。swrole 命令需要使用角色名作為參數，因此我們執行了 swrole so。這個操作將激活 so 角色。
一旦 so 角色處於活動狀態，就可以使用 rolelist -ea 命令列出有效的角色和授權。
圖 10 swrole 命令
6. 現在，oper1 用戶具有了處於活動狀態的 so 角色，並且可以執行 shutdown 命令。
通過為用戶 oper1 添加 so 角色，它允許該用戶在不訪問 root 用戶或者成為 shutdown 組成員的情 況下，執行 shutdown 和 reboot 程序。此外，不需要更改文件對象的 DAC。
在圖 11 中，我們以 oper1 用戶的身份來執行 shutdown 命令。
圖 11 以 oper1 用戶的身份執行 shutdown 命令
注意：應該使用最少權限原則來分配角色。應該避免為用戶分配這樣的角色，其中所包括的授權超過 了該用戶所需要的授權。
激活角色
在缺省情況下，在使用增強 RBAC 的 AIX Version 6.1 中，缺省登錄過程不分配或者激活任何用戶定 義的角色或者相關的授權。用戶在登錄時，將僅具有從 DAC 中所獲得的權限、或者通過執行 setuid 程 序所獲得的任何權限。
要將角色關聯於會話，用戶必須執行 swrole 命令，該命令將激活為該用戶所分配的某個角色。該用 戶只能使用已經分配給他的角色。
激活一個角色並使用相關的授權，這項操作稱為“使用角色會話”。
在缺省情況下，用戶在進入角色會話或者為其會話添加角色時，需要輸入他們的登錄密碼來進行身份 驗證。通過使用 auth_mode 角色屬性，可以選擇將角色配置為不需要進行身份驗證。此外，通過使用 default_roles 用戶屬性，可以將角色配置為在用戶登錄時自動地激活。
切換到一個新的角色會話，將創建一個新的 Shell 會話，但並不繼承以前的角色會話的角色。通過為 角色會話創建一個新的進程 Shell、並將新的角色 id (rid) 分配給該進程，可以完成這項任務。
創建新的角色會話，其過程與 su 命令的過程類似，只不過在角色會話中，僅更改進程的角色 ID，而 不更改 uid 或者 gid。
swrole 命令將允許用戶創建由一個角色或者多個角色組成的角色會話。用戶可以從當前角色會話切換 到新的角色會話，新的角色會話將是一個新的進程，這個新的角色會話不會從先前的角色會話中繼承任何 角色。為了恢復先前的角色會話，用戶必須退出當前的角色會話。
可以通過在會話中調用 rolelist 命令，列出在角色會話中使用的任何角色、或者活動角色集合。此 外，管理員可以使用 rolelist 命令，以列出系統中給定進程的活動角色集合。
角色身份驗證
可以定義或者修改角色，以允許用戶在不需要進行密碼身份驗證的情況下，激活所分配的某個角色。
在缺省情況下，當使用 swrole 命令激活一個角色的時候，需要用戶通過輸入其登錄密碼來進行身份 驗證。
chrole 命令可用於對角色進行修改，以便在激活角色的時候不需要進行身份驗證。
如果沒有對一個角色的 auth_mode 屬性的缺省值進行修改，那麼將不會顯示 auth_mode 屬性或者節 。
在修改了 auth_mode 屬性之後，將顯示相應的節，其值為 auth_mode 屬性的值。
圖 12 顯示了使用 chrole 命令更改 so 角色的 auth_mode 屬性
當最初使用 lsrole 命令來顯示 auth_mode 節的時候，沒有顯示任何節信息或者屬性值。這是因為還 沒有對 auth_mode 的缺省設置進行更改。
在將 auth_mode 設置為 NONE 之後，將顯示相應的節和屬性值，並且當使用 swrole 命令激活 so 角 色的時候，將不再需要進行身份驗證。
要恢復其缺省設置，可以執行 chrole 命令，將 auth_mode 節修改回原始值，以啟用 INVOKER 授權 。在使用 swrole 命令激活 so 角色時，又需要進行身份驗證了。
注意：如果將一個角色修改為允許在不經過身份驗證的情況下進行激活，那麼這將允許用戶在不輸入 其登錄憑據的情況下激活該角色。但這樣有可能會使攻擊者能夠使用空閒的、或者未鎖定的用戶會話來激 活角色，並且在不進行任何身份驗證檢查的情況下執行受限的命令。
角色激活
通過使用 default_roles 用戶屬性，用戶可以選擇將已定義的角色配置為用戶登錄過程的一部分來進 行激活。default_roles 是 AIX V6 中引入的一個用戶屬性，它適用於一些特殊的情況，其中代表用戶所 創建的進程總是需要與給定的角色集合相關聯。
cron 進程是需要使用 default_roles 用戶屬性的情況的一個示例。cron 進程在後台運行，並使用已 定義的用戶執行相應的命令。可以想象，它所執行的某些命令需要相應的授權。這就需要能夠為用戶 ID 指定一組始終處於活動狀態的角色，因為沒有任何機制可以使得 cron 在晚些時候獲得所需的角色。
可以對 default_roles 用戶屬性進行設置，最多包括八個角色名稱、或者設置為特殊值 ALL。設置 default_roles=ALL 將對會話分配所有的用戶角色。如果為用戶分配了八個以上的角色，那麼該會話只能 啟用前八個角色。
