保護 root 用戶的安全
下面的部分將介紹在增強的 RBAC 模式中運行時如何禁用 root 用戶。
選擇保護 root 用戶的安全
當 AIX 系統運行於增強的 RBAC 模式時，可以對系統進行相應的配置，從而使 root 用戶不具有超級 用戶權限，並且將其禁用，以至使 root 用戶帳號失去登錄權限。
通常在 AIX 中，root 用戶的 UID 值為 0，操作系統將其作為一種特權 UID，並允許 root 用戶繞過 強制的安全檢查。通過禁用 root 用戶，可以有效地刪除這些操作系統檢查。
在禁用了 root 用戶之後，對 root 用戶進行了限制，不允許它訪問系統，盡管它將仍然保留文件的 DAC 所有權（如果可以訪問該帳號的話）。盡管 root 用戶仍然可以擁有文件對象，但不能通過 su 命令 、或者遠程登錄、或者從定義的系統控制台來訪問 root 用戶。
傳統的 UNIX 管理依賴於為執行某些特權命令而啟用 root 用戶；對於攻擊者而言，他們也希望啟用 root 用戶，並集中其所有的力量攻擊 root 用戶。
攻擊者可能試圖獲得對 root 用戶的訪問，如果 root 用戶的完整性遭到破壞，那麼攻擊者將可以自 由地執行任何特權命令以實現其惡意的目的。如果獲得了未經授權的 root 用戶訪問權限，那麼攻擊者就 可能對系統造成廣泛的、且不受任何限制的危害。這種故意的損害稱為惡意 root。
在禁用了 root 用戶的增強的 RBAC 系統中，可以將攻擊者可能造成的危害降到最低，因為禁用了 root 用戶。即使攻擊者破壞了現有的網絡安全設施並收到一個登錄提示，但是攻擊者不能以遠程的方式 、或者在控制台、或者通過 su 命令訪問 root 帳號。
在禁用了 root 用戶之後，必須由 root 用戶以外的其他用戶來執行系統管理任務。需要通過一個或 多個其他的用戶帳號來訪問由 root 用戶所擁有的特權命令和文件。
使用 AIX V6 中預定義的 isso、so 和 sa 角色，就是這種方式的一個示例。
重要：isso、so 和 sa 角色可能並不包括管理系統所需的所有特權命令或者授權。
因此在嘗試禁用 root 用戶的功能之前，應該對系統以及正在系統中使用的應用程序進行仔細地分析 。
禁用 root 用戶
通過 setsecconf 命令，可以禁用 root 用戶的各種功能。
在這個場景中，我們首先將 isso 角色分配給 oper1 用戶，這樣一來，我們就可以測試 oper1 用戶 執行禁用或者啟用 root 用戶模式所需的特權命令。
oper1 用戶仍然具有 shutdown_reboot 角色，因此 oper1 用戶仍然能夠執行 reboot 和 shutdown 命令，以使系統重新啟動。
執行下面的命令，然後重新啟動系統，以禁用 root 用戶的功能：
1. 以 oper1 用戶的身份登錄，並執行 swrole 命令啟用 isso 角色：
swrole isso
2. 在進行身份驗證之後，將 runmode 設置為配置模式：
setrunmode -c
3. 執行 setseconf 命令，以禁用 root 用戶：
setsecconf -o root=disable
4. 重新啟動系統。
在這個示例中，我們首先需要交換角色到 shutdown_reboot 角色，並在執行 shutdown -Fr 命令之前 進行身份驗證：
swrole shutdown_reboot shutdown -Fr
現在系統將重新啟動，並且將使用 root=disable 模式重新啟動。
圖 1 顯示了在增強的 RBAC 模式中禁用 root 用戶的操作。
圖 1 在增強的 RBAC 模式中禁用 root 用戶
圖 2 顯示了在禁用 root 用戶的情況下，服務器重新啟動時的控制台輸出。
圖 2 在禁用 root 用戶的情況下重新啟動時的控制台
在執行 setsecconf 命令並禁用 root 用戶之後，root 用戶在系統中仍然是一個有效的用戶標識，但 是不能使用 su 命令、或通過遠程或本地控制台的登錄對其進行訪問。
在禁用 root 用戶時的注意事項
在選擇禁用 root 用戶之後，不再為 root 用戶所擁有的任何進程分配任何特殊功能或者權限。
在禁用了 root 用戶的增強的 RBAC 系統中，應該將任何需要執行特權操作的命令添加到特權命令數 據庫中，並為其分配合適的權限。這將包括由 root 用戶所擁有的任何 setuid 應用程序或者命令；因為 在禁用了 root 用戶之後，對 UID 0 的檢查機制（以繞過強制的安全檢查）將會停用。
在禁用了 root 的環境中，執行 setuid 應用程序或者命令，將可能導致命令或者應用程序的執行不 能可靠地或者成功地完成。
在考慮禁用 root 用戶時，請確保已經確定了原來由 root 用戶所執行的任何操作或者管理任務，並 且已將這些任務分配給了一個或者多個用戶帳號。
要禁用或者啟用 root 用戶，需要重新啟動系統，因此，如果在禁用了 root 用戶之後發現某個命令 或者文件無法訪問或者執行，那麼重新啟用 root 用戶將影響服務器的正常運行。
在這個場景中，要啟用 root 用戶，可以將角色轉換為 isso 角色，執行 setsecconf -o root=enable 命令，並且重新啟動系統。
圖 3 顯示了在增強的 RBAC 模式中啟用 root 用戶的操作。
圖 3 在增強的 RBAC 模式中啟用 root 用戶
重要：應該在嘗試禁用 root 用戶的功能之前，對系統以及正在系統中使用的應用程序進行仔細地分 析。
增強的 RBAC 的 root 禁用模式的匯總
下面對增強的 RBAC 中禁用 root 用戶的相關內容進行了匯總：
只有在運行於增強的 RBAC 模式中時，才應該禁用 root 用戶。
禁用 root 用戶，並不是運行於增強的 RBAC 模式的強制性需求。
在禁用了 root 的環境中，setuid 應用程序或者命令很可能將無法運行。很可能需要將這些命令或者 應用程序添加到特權命令數據庫中，然後進行進一步測試，以確保它們正常運行。
應該在嘗試禁用 root 用戶的功能之前，對系統以及正在系統中使用的應用程序進行仔細地分析。應 該在將系統投入生產之前，執行全面的測試。
isso、sa 和 so 角色可能並不包括管理系統所需的所有特權命令或者授權。
應該將管理系統可能需要的任何特權命令添加到特權命令數據庫。
對於由 root 用戶所擁有的、可能需要由非特權用戶進行訪問的任何特權文件，都需要添加到特權文 件數據庫。
注意：對於每個 WPAR 來說，root 禁用模式都是特定的。這意味著，在一個給定的 WPAR 中可以有選 擇地禁用/啟用 root 用戶的功能。
使用 FPM 命令來減少 SetUID 程序
文件權限管理器（File Permission Manager，FPM）命令可用於管理可執行命令中的 setuid 和 setgid DAC 權限。
通過將 FPM 與增強的 RBAC 結合在一起，管理員可以選擇修改一個或者多個可執行文件中的 setuid 或者 setgid 位，而替代性的，將這些程序作為 RBAC 特權命令來執行。
通過使用 fpm 命令對可執行文件進行修改（刪除 s 位），將不再允許非特權用戶使用有效 UID 0 並 以 root 用戶的身份執行相應的命令。相反，用戶將使用增強的 RBAC 授權和角色來執行 RBAC 特權命令 。
增強的 RBAC 並不需要管理員使用 FPM 刪除 setuid 和 setgid 命令的 s 位，盡管某些管理員所處 的環境需要將 s 位執行保持最小，對於這些管理員來說，以這種方式使用 FPM 是一種非常具有吸引力的 選擇。
如果需要對操作系統環境進行任何修改，應該在嘗試修改 s 位可執行文件之前，對系統以及正在系統 中使用的應用程序進行仔細地分析。
增強的 RBAC 和 WPAR
這個部分將介紹增強的 RBAC 和工作負載分區 (WPAR) 的使用。
限制
在 WPAR 中使用 RBAC 時，將受到下列限制：
在使用 WPAR 時，只支持增強的 RBAC 模式。
僅在系統 WPAR 中支持增強的 RBAC。
系統定義的授權包含於全局環境中。
每個系統 WPAR KST 都將利用全局環境中系統定義的授權。
每個 WPAR 都有它自己的 WPAR KST，其駐留在全局環境內核中。
任何擁有因為使用 WPS 而帶來的權限限制的 WPAR 都將無法通過授權以獲得該權限
圖 4 顯示了增強的 RBAC 和系統 WPAR 授權的使用，其中利用了全局環境系統定義的授權。
圖 4 系統 WPAR 和增強的 RBAC
遷移到增強的 RBAC
這個部分將討論從一個預先存在的 RBAC 環境遷移到增強的 RBAC 模式。
遷移授權
在 AIX V6 之前的版本中，遺留 RBAC 產品的發布版中包含一組有限的預定義授權。雖然這些遺留 RBAC 授權並不是定義於系統的某個文件中，但是可以很容易地將其分配給角色。
在 AIX V6 中，增強的 RBAC 在新的增強的 RBAC 框架之內，支持這些遺留 RBAC 的授權（作為用戶 定義的授權）。在缺省情況下，在位於 /etc/security/authorizations 的 RBAC 授權安全數據庫中提供 了這些用戶定義的授權。
因為 AIX V6 使用了一種新的授權命名約定，所以對 AIX 中舊的授權名稱的檢查進行了修改，需要以 額外地增加對新的增強的 RBAC 授權的檢查。
表 1 列出了遺留模式中的預定義授權和相應的增強模式中的系統定義的授權。
現有的遺留模式授權 增強的模式授權 Backup aix.fs.manage.backup Diagnostics aix.system.config.diag DiskQuotaAdmin aix.fs.manage.quota GroupAdmin aix.security.group ListAuditClasses aix.security.audit.list PasswdAdmin aix.security.passwd PasswdManage aix.security.passwd.normal UserAdmin aix.security.user UserAudit aix.security.user.change RoleAdmin aix.security.role Restore aix.fs.manage.restore
重要：在遷移完成之後，系統管理員必須驗證根據具體的環境對授權和角色是否進行了相應的定義。
角色遷移
當通過遷移安裝的方法在 AIX V6 之前的 AIX 版本中對現有的系統進行更新 時，/etc/security/roles 文件的遷移在維護當前角色能力的同時，將嘗試對該文件進行更新以實現新的 增強的 RBAC 功能。
將保留和修改該文件中的角色定義，以包括一個唯一的角色 ID，以便該角色可以在新的增強的 RBAC 框架中生效。
對於 /etc/security/roles 文件中出現的任何授權，以及未知的預定義授權，都將認為是用戶定義的 授權。在遷移期間，將在本地的 /etc/security/authorizations 授權數據庫中為這些授權名稱添加相應 的條目。除了遷移遺留 RBAC 角色定義之外，新的預定義角色將追加到該文件中。
RBAC 遠程數據庫支持
這個部分將討論使用 LDAP 的增強的 RBAC 的遠程數據庫支持。
使用 LDAP 作為 RBAC 數據庫存儲庫的先決條件
在使用 LDAP 作為 RBAC 數據庫存儲庫之前，必須滿足下面的先決條件：
必須配置一個 LDAP 服務器，並且可用於承載 RBAC 安全數據庫。
在 LDAP 服務器和 LDAP 客戶端之間，必須提供網絡連接。
LDAP 客戶端必須安裝 LDAP 客戶端文件集。
LDAP 客戶端必須運行於增強的 RBAC 模式中。
要在 LDAP 服務器中承載 RBAC 安全數據庫，必須將 RBAC 數據庫存儲庫填充到 LDAP 服務器中。
AIX V6 提供了 rbactoldif 命令，該命令可用於讀取本地 RBAC 數據庫中的數據，並采用適合於 LDAP 的格式輸出這些數據。可以將 rbactoldif 所生成的輸出保存到一個文件，然後用這個文件來填充 LDAP 服務器。
在使用 rbactoldif 命令生成 RBAC 安全數據庫數據之後，可以使用 ldapadd 命令將這些數據上傳到 LDAP 服務器。
rbactoldif 命令將使用下列本地系統數據庫來為 LDAP 生成 RBAC 安全數據庫數據：
/etc/security/authorizations
/etc/security/privcmds
/etc/security/privdevs
/etc/security/privfiles
/etc/security/roles
應該考慮在 LDAP 中的什麼位置存儲 RBAC 安全數據庫數據。我們建議，LDAP 中的 RBAC 數據應該放 在與用戶和組數據相同的父 DN 之下。然後，應該根據所選擇的安全策略，對這些數據的 ACL 進行適當 調整。
限制：存儲在 LDAP 中的授權數據庫將僅包含用戶定義的授權。系統定義的授權不能存儲於 LDAP 中 ，而是保留在各個客戶端系統的本地。
LDAP 客戶端的 RBAC 配置
為了使用存儲在 LDAP 中的 RBAC 安全數據庫數據，必須將一個 AIX V6 系統配置為 LDAP 客戶端。 mksecldap 命令可用於將系統配置為 LDAP 客戶端。
mksecldap 命令將動態搜索指定的 LDAP 服務器，以確定授權、角色和特權命令/設備/文件數據的位 置，並將結果保存到 /etc/security/ldap/ldap.cfg 文件。
在成功地通過 mksecldap 命令將系統配置為 LDAP 客戶端之後，必須進一步對該系統進行配置，以使 得 LDAP 作為 RBAC 數據的查找域。必須對 /etc/nscontrol.conf 文件進行修改，以便在那些將要存儲 於 LDAP 的數據庫的 secorder 屬性中包括 LDAP。
在將客戶端系統配置為 LDAP 客戶端和 RBAC 數據的查找域之後，可以對客戶端守護進程 secldapclntd 進行配置，使其定期地從 LDAP 中檢索 RBAC 數據，並將數據發送到內核安全表 (KST)。 secldapclntd 通過執行 setkst 命令來更新 KST。
通過 /etc/security/ldap/ldap.cfg 中的 rbacinterval 屬性，可以對 secldapclntd 守護進程所使 用的、從 LDAP 中檢索 RBAC 數據的時間段進行配置。如果 /etc/nscontrol.conf 文件正在使用 LDAP 和本地文件數據庫，那麼 setkst 命令將根據 /etc/nscontrol.conf 文件中的定義，檢索給定數據庫的 條目合並副本，然後將結果數據加載到客戶端內核安全表。
在缺省情況下，rbacinterval 屬性的值為 3600，這表示將 KST 的自動更新設置為每小時一次。如果 更改了 rbacinterval 屬性，那麼應該運行 restart-secldapclntd 命令，以便重新啟動 secldapclntd 守護進程。
注意：如果 rbacinterval 為 0，那麼僅當管理員在客戶端系統中手動地執行 setkst 命令時，才能 更新 KST。
域名服務控制文件
系統管理員可以將 RBAC 數據定義為嚴格地駐留在本地文件中、嚴格地駐留在 LDAP 中、或者將本地 文件和 LDAP 中的數據進行合並。通過為名稱服務控制文件 /etc/nscontrol.conf 中的每個 RBAC 安全 數據庫配置查找域，可以對這個選項進行設置，以使其生效。
/etc/nscontrol.conf 文件可以單獨地指定授權、角色、特權命令、設備和文件數據庫的搜索次序。 可以為這五個 LDAP 安全數據庫中的每一個數據庫混合使用本地文件和 LDAP、或者組合的域。
通過 secorder 屬性（以逗號進行分隔的域的列表），可以在 /etc/nscontrol.conf 文件中指定數據 庫的搜索次序。域可以是 LDAP、或者文件，其中文件表示 LDAP 客戶端的 /etc/security 目錄中的本地 數據庫文件。
圖 5 顯示了 /etc/nscontrol.conf 文件中授權數據庫配置的一個示例。
圖 5 /etc/nscontrol.conf 文件的示例
圖 5 中的示例說明，對授權安全數據庫的任何域查找查詢應該首先在 LDAP 中進行搜索。如果在 LDAP 數據庫中沒有找到授權條目，那麼將搜索本地數據庫。
可供客戶端系統使用的授權集合，是由 LDAP 提供的授權和本地文件提供的授權合並而成的。這個合 並不是將來自這兩個域的值簡單地組合在一起，而是這些值的一個並集。這個合並包含來自第一個查找域 的 RBAC 安全數據庫，以及來自其余查找域的任何附加 RBAC 安全數據庫。
對於圖 5 中的配置，將包括來自 LDAP 的授權，然後將來自 /etc/security/authorizations 本地文 件的那些唯一的授權添加到結果中。
在進行 RBAC 數據庫的修改和刪除時，將嘗試在列出的第一個域中進行，只有在第一個域中沒有找到 相應條目的情況下，才嘗試在後續的域中進行。
在圖 5 中，將首先在 LDAP 數據庫中嘗試進行修改和刪除操作。如果 LDAP 數據庫不包含該授權，那 麼才會在本地文件數據庫中進行修改和刪除。
在進行創建時，始終是在 secorder 屬性中列出的第一個域中創建新的 RBAC 數據庫條目。在圖 5 中 ，將在 LDAP 數據庫中創建新的授權。
如果 /etc/nscontrol.conf 文件中沒有數據庫的條目、或者該文件根本不存在，那麼對 RBAC 數據庫 的查詢和修改將僅在本地文件數據庫中進行。
可以將 LDAP 服務器僅用於所選擇的安全數據庫。可以通過 chsec 命令對個別數據庫的配置進行設置 。
可以通過 lssec 命令列出數據庫的配置。
要將授權數據的檢索次序配置為先從 LDAP 然後從本地文件進行檢索，可以執行下面的命令：
chsec -f /etc/nscontrol.conf -s authorizations -a secorder=LDAP,files
/etc/nscontrol.conf 文件中的配置可用於控制庫和命令行接口。應用程序可以通過 getsecorder() 接口，檢索某個數據庫的 secorder 屬性的當前值。通過使用 setsecorder() 接口，可以覆蓋進程的 secorder 屬性值。
對 LDAP 的 RBAC 命令支持
所有的 RBAC 數據庫管理命令都遵循 /etc/nscontrol.conf 文件中配置的數據庫查找次序。
在缺省情況下，數據庫管理命令將遵循 /etc/nscontrol.conf 文件的 secorder 屬性中所定義的查找 次序。
如果需要的話，可以通過在任何命令中使用 -R 選項，然後指定數據庫（LDAP 或者文件），以此指定 查找次序。
如果為一個 RBAC 管理命令指定了 -R 選項，那麼將強制對指定的域執行該操作，並覆蓋 /etc/nscontrol.conf 中的配置。
可以將下列 RBAC 數據庫管理命令用於遠程域支持：
mkauth、chauth、lsauth 和 rmauth
mkrole、chrole、lsrole 和 rmrole
setsecattr、lssecattr 和 rmsecattr
setkst
圖 6 顯示了帶 -R 選項的 lsrole 數據庫管理命令，用於列出本地文件數據庫（而不是 LDAP 數據庫 ）。
圖 6 使用 -R 標志的 lsrole 數據庫管理命令
可以使用 setkst 命令，以實現 /etc/nscontrol.conf 中所包含的配置。setkst 命令將根據 /etc/nscontrol.conf 文件中的定義，檢索給定數據庫的條目合並副本，然後將結果數據加載到客戶端內 核安全表。
RBAC 場景
在這個部分中，我們將討論兩個 RBAC 場景。
場景 1 涉及到 RBAC 角色的劃分，以及特權命令的定義。
場景 2 涉及到在 LDAP 服務器中承載增強的 RBAC 安全數據庫。
場景 1：角色的劃分
在這個場景中，要求管理員定義一個增強的 RBAC 角色，以便存儲支持專業人員可以使用該角色來維 護 AIX V6 系統中的存儲環境。
存儲支持專業人員負責創建文件系統，並管理分配給系統的物理卷。
存儲支持專業人員已經列出了日常的，以及服務支持所需的特權命令。這些命令如下所示：
rmdev
mkdev
cfgmgr
mklv
rmlv
crfs
mount
umount
通過將角色和授權配置為僅包含存儲支持專業人員執行這些命令所需的相關命令，管理員可以實現下 列方面的內容：
保持 root 密碼不改變。
向存儲支持專業人員提供授權，以便僅使用有限數量的特權命令。這將限制非特權用戶對敏感數據的 訪問。
將 root 用戶誤用的可能性減到最小。
將系統定義修改（無論是由意外，還是惡意目的造成的）的可能性減到最小。
符合最少特權的原則。
為了創建存儲支持專業人員角色，我們必須首先完成以下操作：
1．使用 lssecattr 命令，以確定目前特權命令數據庫中是否存在存儲支持專業人員所請求的命令。 如果它們存在，那麼在 accessauth 節中記下該值，這樣一來，就可以將這個授權添加到某個角色中。
圖 7 顯示了帶 accessauth 標志的 lssecattr 命令，用於顯示每個特權命令的授權。
lssecattr 命令輸出產生一個錯誤，說明特權命令數據庫中沒有定義 cfgmgr 命令，因此在這個場景 的步驟 2 中，將在特權命令數據庫中定義 cfgmgr 命令。
圖 7 使用 accessauth 標志的 lssecattr 命令
accessauth 字段中顯示的授權稍後將在步驟 5（在創建用戶定義的角色時）中使用。
2. 在步驟 1 中我們看到，特權命令數據庫中沒有定義 cfgmgr 命令。如果一個命令在特權命令數據 庫中並不存在，那麼在將該命令作為 RBAC 特權命令使用之前，必須在 RBAC 特權命令數據庫中定義它。
要將一個命令添加到特權命令數據庫，請遵循下面的步驟：
a. 創建一個用戶定義的授權。
在這個場景中，我們將創建 ibm.aix.management.cfgmgr 授權。
圖 8 顯示了用於創建用戶定義的授權 ibm.aix.management.cfgmgr 的 mkauth 命令
注意：因為這是一個新的授權，並且沒有 IBM AIX 用戶定義的授權，所以我們首先在層次結構中創建 父層次。
b. 在定義了用戶定義的授權之後，可以使用 tracepriv 命令，以確定該命令所需的哪些權限不在特 權命令數據庫中，並將它們添加到特權命令數據庫。
要在特權命令數據庫中定義 cfgmgr 命令，我們首先需要確定成功地執行該命令需要哪些權限。要確 定這些權限，我們可以使用 tracepriv 命令。
在運行 tracepriv 命令時，將列出權限清單，可以將輸出顯示在控制台或者重定向到一個文本文件。 在這個場景中，我們將輸出重定向到 /tmp/cfgmgr.tracepriv.output 文件。
圖 9 顯示了針對 cfgmgr 命令執行的 tracepriv。-f 標志用於表示 forks。-e 標志用於表示 execs 。
圖 9 tracepriv 命令，重定向到 /tmp/cfgmgr.tracepriv.output cfgmgr
注意：也可以由 root 用戶以外的用戶來運行 tracepriv 命令，但該用戶必須對其 Shell 進行修改 ，將 EPS 和 MPS 設置為 PV_ROOT。這個方法可用於確保正確地跟蹤 GETUID() 檢查。
在完成了 cfgmgr 命令之後，將在 /tmp/cfgmgr.tracepriv.output 文件中列出 cfgmgr 命令所需的 權限。
圖 10 顯示了 tracepriv 命令輸出的第一頁內容，並將其寫入到 /tmp/cfgmgr.tracepriv.output 文 件。
圖 10 來自 cgfmgr 命令的 tracepriv 輸出
注意：圖 10 中沒有列出執行 cfgmgr 命令所需權限的完整列表，這是因為輸出內容過長。稍後在討 論 setsecattr 命令的場景中，將列出這些命令。
通過閱讀 tracepriv 的輸出，我們可以確定在執行 cfgmgr 命令時所使用的 15 個權限的名稱。將在 setsecattr 命令中使用這些權限，以便在特權命令數據庫中定義 cfgmgr 命令。
c. 使用 setsecattr 命令，將該命令添加到特權命令數據庫。
現在將 tracepriv 命令所列出的權限作為 innateprivs 節中的固有權限，分配給 cfgmgr 命令。
將步驟 1 中定義的授權 ibm.aix.management.cfgmgr 分配給 authorization 節中的 cfgmgr 命令。
圖 11 顯示了用於在特權命令數據庫中定義 cfgmgr 命令的 setsecattr 命令。
圖 11 使用 setsecattr 定義 cfgmgr 命令
當在特權命令數據庫中定義了 cfgmgr 命令之後，我們可以使用 lssecattr 命令顯示其狀態。
圖 12 顯示了 lssecattr 命令。
圖 12 使用 lssecattr 顯示特權命令 cfgmgr
現在，已經將 cfgmgr 命令添加到了特權命令數據庫中，並且將其作為一個 RBAC 特權命令。
3. 確定是否存在一個現有的、可供使用的角色（其中包含執行存儲支持專業人員的命令列表所需的授 權）。請確保符合最少特權的原則。
如果系統中沒有包含所需授權的現有角色，那麼創建一個用戶定義的角色。
在這個場景中，我們將定義 storage_support 角色，並為其分配授權 ibm.aix.management.cfgmgr, 以及圖 7 中所列出的授權。
圖 13 顯示了在定義 config_manager 角色的時候如何使用 mkrole 命令。
圖 13 mkrole 命令
使用 lsrole 命令，可以顯示用戶定義的角色的屬性。
圖 14 顯示了 lsrole 命令的使用。
圖 14 lsrole 命令
4. 使用 setkst 命令更新內核安全表 (KST)。
所有的 RBAC 安全檢查都在 AIX 內核中執行。如果不執行 setkst 命令，對 RBAC 安全數據庫所做的 更改將不會更新到 AIX 內核中。
圖 15 中顯示了 setkst 命令。
圖 15 使用 setkst 命令更新內核安全表
5. 使用 chuser 命令，將用戶定義的角色 storage_support 分配給存儲支持專業人員用戶。
存儲支持專業人員的 AIX 用戶名為 stor1。
在圖 16 中，我們列出了分配給 stor1 用戶的角色（如果存在的話）。
圖 16 lsuser 命令
通過使用 lsuser 命令，我們可以確定還沒有為 stor1 用戶分配角色。
使用 chuser 命令，將 storage_support 用戶定義的角色分配給 stor1 用戶。
圖 17 顯示了用於將 storage_support 角色分配給 stor1 用戶的 chuser 命令。
圖 17 使用 chuser 命令來分配角色
現在，stor1 用戶可以進行登錄，並使用 swrole 命令激活 storage_support 角色。
通過以 stor1 用戶的身份進行登錄，我們可以測試分配給 stor1 用戶的角色和特權命令。
圖 18 顯示了由 stor1 用戶執行的 lspv 命令。僅為該系統分配了一個物理卷，hdisk0。
然後，stor1 用戶使用 swrole 命令激活 storage_support 角色。
圖 18 使用 swrole 命令的 stor1 用戶
在激活 storage_support 角色之後，stor1 用戶現在就可以執行分配給 storage_support 角色中的 授權的特權命令了。
存儲支持專業人員從存儲陣列中為系統分配了另一個磁盤，並希望對它進行配置。因為 stor1 用戶已 經激活了 storage_support 角色，現在可以由 stor1 用戶執行 cfgmgr 命令。
圖 19 顯示了 stor1 用戶正在執行特權 cfgmgr 命令。
圖 19 正在執行特權命令 cfgmgr 的 stor1 用戶
使用 cfgmgr 命令對剛分配的磁盤進行配置，並將其定義為 hdisk1。
通過使用增強的 RBAC，我們已經成功地將角色分配給了一個普通用戶，以便允許他執行所選擇的一組 特權命令。
我們的方法符合最少特權的原則，沒有為 stor1 用戶授予完成存儲支持任務之外的任何其他命令或者 文件的訪問權限。
場景 2：遠程 RBAC 安全數據庫
在這個場景中，我們將配置增強的 RBAC 安全數據庫，使其遠程地駐留於 LDAP 服務器中。
在使用 LDAP 作為 RBAC 數據庫存儲庫之前，必須滿足下面的先決條件：
_ 必須配置了一個 LDAP 服務器，並且可用於承載 RBAC 安全數據庫。
_ LDAP 服務器必須包含用於 RBAC 安裝的 LDAP 模式（Schema）。RBAC 模式位於 AIX V6 客戶端的 /etc/security/ldap/sec.ldif 文件中。
_ 在 LDAP 服務器和 LDAP 客戶端之間，必須提供網絡連接。
_ LDAP 客戶端必須安裝 LDAP 客戶端文件集。
_ LDAP 客戶端必須運行於增強的 RBAC 模式中。
在這個場景中，管理員選擇在 LDAP 服務器中承載 RBAC 安全數據庫。LDAP 服務器以前由 LDAP 管理 員進行了相應的配置。
管理員選擇在 LDAP 服務器中承載所有的五個 RBAC 安全數據庫，並使用 LDAP 服務器作為任何 RBAC 數據庫的第一搜索位置。
重要：接下來的過程概述了為這個環境配置承載於 LDAP 服務器中的遠程數據庫所需的過程。您的環 境可能與該場景的環境有所不同，因此在配置由遠程 LDAP 承載的 RBAC 安全數據庫之前，請咨詢您的 LDAP 管理員。
1. 導出 RBAC 安全數據庫。
必須采用適當的格式（可以將其更新到 LDAP 服務器）導出 RBAC 安全數據庫。通過使用 rbactoldif 命令，可以將 RBAC 安全數據庫導出到一個文件，可以使用 ldapadd 命令將該文件作為輸入加載到 LDAP 服務器中。
可以由管理員來定義 rbactoldif 命令所使用的文件的位置和名稱。與所有的系統數據文件一樣，該 文件不應該位於某個公開的位置。該文件僅用於 LDAP 數據庫的初始更新，並且在完成初始 LDPAP 數據 庫更新之後，可以刪除該文件。我們的管理員選擇了 root 用戶的 home 目錄，並將該文件命名為 /root/RBAC_DB.txt。
如果僅在 LDAP 服務器中承載所選擇的 RBAC 安全數據庫，那麼可以使用帶 -s 選項的 rbactoldif 命令。
-s 選項允許在 LDAP 中承載所選擇的數據庫。在這個場景中，管理員選擇使用 LDAP 承載所有的 RBAC 安全數據庫。
圖 20 顯示了 rbactoldif 命令。我們選擇了 aixdata 的“cn”。將該文件的輸出寫入到 /root/RBAC_DB.txt。
圖 20 使用 rbactoldif 命令導出 RBAC 安全數據庫
可以使用文本查看器/編輯器來查看 rbactoldif 命令輸出的 RBAC 安全數據庫。在圖 20 中，我們使 用了more 的命令，以便顯示 /root/RBAC_DB.txt 文件中數據的格式。
2. 將 RBAC 安全數據庫更新到 LDAP。
ldapadd 命令可以使用 /root/RBAC_DB.txt 文件中的數據更新 LDAP 數據庫。/root/RBAC_DB.txt 文 件包含 RBAC 安全數據庫中的信息，即我們在步驟 1 中所導出的信息。
在配置 LDAP 客戶端之前，請確保 LDAP 服務器已經安裝了 RBAC 模式。AIX V6 在 /etc/security/ldap/sec.ldif 文件中附帶了 RBAC 的 LDAP 模式。LDAP 管理員可能需要使用 ldapmodify 命令更新 LDAP 服務器中的模式。
在這個場景中，我們使用了帶 -c 選項的 ldapadd 命令，這將導致該命令忽略可能已經存在的條目， 並繼續執行。
圖 21 顯示了使用來自 /root/RBAC_DB.txt 文件的 RBAC 安全數據庫信息更新 LDAP 服務器的 ldapadd 命令。
圖 21 ldapadd 命令
現在，ldapadd 命令已經使用 RBAC 安全數據庫更新了 LDAP 服務器。
3. 配置 LDAP 客戶端。
首先必須安裝 LDAP 客戶端文件集，然後可以使用 mksecldap 命令配置 LDAP 客戶端。
注意：具體的 LDAP 客戶端文件集可能取決於您的特定 AIX 安裝。
在發表本書的時候，在這個場景中使用的 LDAP 客戶端文件集是 32 位客戶端 idsldap.clt32bit60。
mksecldap 命令將配置 LDAP 客戶端，並動態搜索指定的 LDAP 服務器，以確定授權、角色、特權命 令、設備和文件數據的位置，並將結果保存到 /etc/security/ldap/ldap.cfg 文件。
圖 22 顯示了 mksecldap 命令的使用。
圖 22 mksecldap 命令
4. 更新 RBAC 安全數據庫域的查找次序。
在成功地通過 mksecldap 命令將系統配置為 LDAP 客戶端之後，必須進一步對該客戶端進行配置，以 使得 LDAP 作為 RBAC 安全數據庫的查找域。
注意：圖 22 中所使用的配置變量是針對這個示例環境的，可能並不適合於您的環境。在配置您的 LDAP 客戶端之前，請咨詢您的 LDAP 管理員。
RBAC 使用 /etc/nscontrol.conf 文件以確定 RBAC 安全數據庫域的查找次序。
在缺省情況下，RBAC 安全數據庫位於 /etc/security/ 目錄中。當 RBAC 安全數據庫存儲於 LDAP 服 務器中時，必須更新 /etc/nscontrol.conf 文件，以使 LDAP 服務器中所存儲的每個 RBAC 安全數據庫 都包括該 LDAP 域。
在這個場景中，管理員選擇將五個 RBAC 安全數據庫都存放於 LDAP 服務器中，因 此，/etc/nscontrol.conf 文件必須為這五個 RBAC 安全數據庫更新 secorder 節。
圖 23 顯示了在配置為使用 LDAP 服務器作為 RBAC 安全數據庫的查找域之前的 /etc/nscontrol.conf 文件。
圖 23 /etc/nscontrol.conf 文件，只解析本地文件
可以使用 chsec 命令更新 /etc/nscontrol.conf 文件，以更新每個 RBAC 安全數據庫的 secorder 節。
圖 24 顯示了 chsec 命令，對 /etc/nscontrol.conf 文件的 secorder 節進行更新，以便將 LDAP 域設置為第一查找域。
圖 24 使用 chsec 命令更新 /etc/nscontrol.conf 的 secorder 節
圖 25 顯示了在配置為使用 LDAP 服務器作為 RBAC 安全數據庫的查找域之後的 /etc/nscontrol.conf 文件
5. 定義內核安全表 (KST) 更新方法。
通過在 /etc/security/ldap/ldap.cfg 文件的 rbacinterval 節中設置一個值，可以將 /usr/sbin/secldapclntd 守護進程配置為自動地更新客戶端 KST。
缺省情況下，在 AIX V6 中，將 rbacinterval 節設置為 3600 秒，但該節內容被注釋 了。/usr/sbin/secldapclntd 守護進程還有一個硬編碼值，設置為 3600 秒。如果沒有為 /etc/security/ldap/ldap.cfg 文件的 rbacinterval 節指定值，那麼 /usr/sbin/secldapclntd 守護進 程將實現守護進程代碼中硬編碼的值 3600。
如果在 rbacinterval 節中指定了一個值，那麼 rbacinterval 節中的值將用於確定 KST 的更新頻率 。如果 rbacinterval 節的值為 0，意味著禁用了 KST 的自動更新，並且對 KST 所做的任何更新都需要 使用 setkst 命令手動地執行。
圖 26 顯示了 /etc/security/ldap/ldap.cfg 文件中 rbacinterval 節的缺省設置。
圖 26 /etc/security/ldap/ldap.cfg 文件中的 rbacinterval 節
注意：為了強制從 LDAP 數據更新 KST，可以從命令行執行 setkst 命令。
6. 使用 RBAC 數據庫管理命令測試域查找。
通過執行 RBAC 數據庫管理命令，管理員可以確保域查找任務的正常運行。
通過使用不帶 -R 選項的 mkrole 命令，可以在 /etc/nscontrol.conf 文件的 secorder 節所定義的 第一個數據庫中定義該角色。
在圖 27 中，我們使用 mkrole 命令以定義命名為 test_role 的角色。secorder 節將域查找定義為 LDAP 文件，因此將在 LDAP 數據庫中定義 test_role 角色。
圖 27 顯示了 mkrole 命令。
圖 27 在 LDAP 中使用 mkrole 命令定義角色
通過使用 lsrole 命令，我們可以看到，在 LDAP 數據庫中已經定義了這個角色，而並沒有在本地 /etc/security/roles 文件中列出。
這顯示 RBAC 安全數據庫的域查找已經按照 /etc/nscontrol.conf 字段中的定義正常工作，並且 LDAP 客戶端和服務器通信都是活動的。
將在 LDAP 數據庫中創建任何新的 RBAC 定義。如果管理員決定在本地文件的 RBAC 安全數據庫中創 建 RBAC 定義，那麼可以通過使用 -R 選項，以控制 RBAC 數據庫管理命令查找。
圖 28 顯示了管理員使用帶 -R 選項的 mkrole 命令，以便在本地 RBAC 安全數據庫中定義 test_role_local。
圖 28 帶 -R 選項的 lsrole 命令
當在不使用特定域的情況下執行 lsrole 命令的時候，該命令將返回 test_role_local 信息，因為根 據域搜索的定義，在搜索次序中首先是文件域、然後是 LDAP 域。
當執行 lsrole -R LDAP test_role_local 命令的時候，將搜索次序限制為 LDAP 數據庫，其中沒有 定義也無法列出該角色。
lsrole -f file test_role_local 命令可以列出本地文件數據庫中的角色，並忽視 LDAP 數據庫搜索 。
