簡介
過去，由單一用戶（root 用戶）控制系統的安全機制。root 用戶決定誰可以登錄、誰可以訪問數據 、哪些進程有權進入內核模式等。但是，單一 root 用戶的缺點是，如果未經授權的人控制了根用戶，系 統就非常容易受到攻擊。
為了避免這個問題，AIX 的最新版本（5.3TL07 和 6.1）引入了 RBAC 和多級安全性 (MLS) 等新的安 全特性，還在傳統的基於 root 用戶的身份驗證中增加了其他特性，比如 Trusted Execution (TE)、 Encrypted File System (EFS) 等。
本文通過示例解釋如何理解和應用 RBAC 和 MLS 等新特性。
安全管理概述
傳統機制
RBAC
傳統機制
可以使用 DAC（Discretionary Access Control，自主訪問控制）控制對數據的訪問（按進程/文件關 系）。但是，具有所有特權的 root 用戶是單一用戶。 root 用戶可以進行任何訪問控制和執行任何操作 。這可能造成嚴重的安全威脅。
另外， root 用戶常常擔任系統管理員、安全官（維護安全策略）和系統操作員（執行日常活動）等 許多職位。由單一用戶控制系統，其他用戶完全無法控制系統中的活動。
RBAC 可以把 root 用戶的角色和授權分配給多個用戶。本文解釋 RBAC 如何改進系統的安全性。
RBAC
傳統的 AIX 系統具有有限的授權集，可以使用它們決定對某些管理命令的訪問。下面的示例顯示 passwd 命令就是一個 setuid 程序，setuid 程序有權作為非 root 用戶執行。它還能夠作為非 root 用 戶修改 /etc/security/passwd 文件。DAC 不允許這麼做。
passwd 命令等 setuid 程序
$ ls -l 'which passwd'
-r-sr-xr-x 1 root security 40014 May 07 2008 /usr/bin/passwd
# ls -l /etc/security/passwd
-rw------- 1 root security 467 Mar 10 23:48 /etc/security/passwd
這會導致嚴重的風險，任何人只要通過惡意的 setuid 程序控制了 root shell，就能夠做任何事。
在 AIX 第 6 版之前， root 用戶的部分權力可以分配給非 root 用戶。不同的 root 用戶任務（命 令）具有不同的授權。這些授權分組為角色並分配給不同的用戶：
任務 -> 授權
授權 -> 角色
角色 -> 用戶
但是，root 用戶仍然是惟一的最高權威。能夠訪問 root 用戶的人可以做任何事。
從 AIX 第 6 版開始，改進了基於角色的訪問機制。
可以禁用 root 訪問。
把 root 任務分配給系統定義的三個用戶。
根據用戶的責任分配特權、授權和角色。
這樣就消除了通過單一路徑破壞系統的可能性。
授權、角色和特權的工作方式。
授權分配給命令。
角色分配給用戶。
特權與特定的進程相關聯。
為了執行命令，需要把顯式的特權分配給命令，通過授權控制它們的執行。
系統給某些命令預先分配了授權，給系統定義的用戶分配了角色。
另外，管理員用戶可以給可執行程序提供（用戶定義的）授權並把授權分配給角色。每個用戶都被分 配一個角色。
因此，具有已定義角色的用戶應該能夠執行任何授權的命令。
shutdown 命令
命令：Shutdown
授權：aix.system.boot.shutdown
角色：isso, so
特權：Root privileges
具有信息系統安全官（ISSO）或相似角色的用戶能夠執行關機嗎？
是的。這個用戶的角色允許執行關機。通過前面的示例可以看出，只有具有這些角色、授權和特權的 用戶能夠執行關機。
惡意用戶是否可能獲得 ISSO 角色並使用自己的 shutdown 程序攻擊系統？
不可能。因為這裡的惡意用戶是一個惡意管理員，他不具有做所有事的完整授權。另外，使用標簽 (MLS) 在系統級執行另一級檢查以改善安全性，這會檢查其他一些特權。
這裡要理解的要點是，具有管理員授權的用戶只能分配授權和角色。控制管理員用戶的惡意用戶無法 做任何事，因為單靠管理員無法做任何破壞性的事。
只允許特定的用戶執行特定的操作。單一 root 用戶的責任被分配給多個用戶。這樣就提高了安全性 。
在授權層次結構中，系統定義的授權以 aix 開頭（見前面的示例，這些授權可能不能修改或刪除）。
root 用戶有什麼變化？
誰替代 root 用戶的角色？
可以禁用對系統的 root 訪問並通過一個或多個用戶賬號執行所有任務。
AIX V6 有三個預定義的角色，它們分配給三個預定義的用戶：
ISSO，信息系統安全官（Information System Security Officer）
SO，系統操作員（System Operator）
SA，安全管理員（Security Administrator）
下表定義這些用戶的角色和授權：
表 1. 預定義用戶的預定義角色
用戶 角色 責任 ISSO ISSO 建立和維護安全策略命令和示例
下表給出一些命令的詳細信息，幫助您了解如何使用授權和角色。
表 2. 命令的詳細信息
任務 命令 創建授權 mkauth (auth_name) 或 smitty rbac-> Authorizations-> Add an Authorization ->Authorization Name 檢驗授權 lsauth 把命令與授權關聯起來 setsecattr -c accessauths= (auth_name) (command) 創建角色 mkrole authorizations= (auth_name) (role name) 把角色與用戶關聯起來 chuser roles=(role_name) (user name)
請通過以下示例了解這些命令：
如何作為 testuser 執行 shutdown 命令
步驟 A：創建和分配（用戶定義的）授權和角色：
mkauth test_auth
setsecattr -c accessauths=test_auth shutdown
mkrole authorizations=test_auth test_role
chuser roles=test_role testuser
setkst
步驟 B：執行
作為 testuser 登錄
使用以下命令切換到 test_role 角色：
swrole test
（提示輸入 testuser 的密碼）
使用以下命令檢查 testuser 是否有角色：
rolelist -e
這顯示相關聯的角色是 test_role
執行 shutdown 命令
到目前為止，已經講解了如何使用授權和角色。前面的示例解釋如何給非 root 用戶分配執行 shutdown 等命令的授權。這個示例只是為了解釋 RBAC 的使用方法。並不建議把執行 shutdown 等命令 的權力分配給非 root 用戶。下面的示例說明創建用戶和設置用戶的密碼不是單一用戶的責任。需要使用 多個角色（用戶）創建用戶和設置用戶的密碼。
如何創建用戶並修改和設置用戶密碼
1. 作為 isso 登錄
2. swrole isso
3. mkuser (user_name)
4. 作為 so 登錄
5. swrole so
6. passwd (user_name)
這說明如何分配角色和授權，以及在沒有正確授權的情況下很難篡改活動。
如何掛載文件系統
1. 作為 isso 登錄
a. swrole isso
2. 掛載文件系統
a. mount: Write permission is required to mount over /mnt. - FAILS
3. 作為 so 登錄
a. swrole so
b. 掛載文件系統
c. 用 df 命令檢查掛載。 - SUCCEEDS
這樣就把 root 用戶的責任分配給了其他用戶，降低了安全風險。
總之，可以把授權分配給可執行命令。把角色分配給用戶，具有已定義角色的用戶應該能夠執行命令 。在 RBAC 授權的基礎上，檢查 DAC 權限。要想繞開 DAC，需要特權。
特權
到目前為止，您已經了解了授權和角色如何增強系統的安全性。現在，看看特權在這個安全系統中的 作用。
進程滿足授權之後，還需要特權才能執行命令。
即使命令和進程有必需的授權，它們仍需特權才能訪問文件。
特權提供設備訪問控制。
簡單地說，在執行系統調用等特權操作之前，操作系統使用授權判斷是否符合條件，
特權的示例
lsconf 示例
lsconf 不是特權命令，它沒有執行特權操作所需的授權。
按照 DAC 確定訪問權限。
它具有以下 DAC 權限：
# ls -l 'which lsconf'
-r-xr-xr-x 2 root system 12712 Mar 14 2008 /usr/sbin/lsconf
具有 DAC 特權的任何人都可以執行 lsconf。有意思的是，lsconf 命令在內部執行 bootinfo 等命令 ，而 bootinfo 命令是一個特權命令。這意味著用戶需要授權和特權才能執行 bootinfo。因此，沒有所 需授權的用戶無法執行 bootinfo。
bootinfo 示例
命令：bootinfo -k
授權和特權：
$ lssecattr -c 'which bootinfo'
/usr/sbin/bootinfo accessauths=aix.system.boot.info innateprivs=PV_DAC_R,
PV_DAC_W,PV_DEV_CONFIG,PV_KER_RAS,PV_MAC_,PV_MIC secflags=FSF_EPS
DAC 權限：
$ ls -l 'which bootinfo'
-r-xr-x--- 1 bin bin 13984 Mar 14 2008 /usr/sbin/bootinfo
在這裡，通過一個角色把授權 aix.system.bootinfo 分配給用戶，這個用戶應該能夠執行 bootinfo 命令。但是，DAC 不允許任何非 root 用戶執行這個文件。
具有所需授權但沒有 DAC 權限的用戶有可能執行命令嗎？
是的，如果進程有執行命令所需的特權，就可能出現這種情況。在這個示例中，如前面的輸出所示， bootinfo 具有 PV_DAC* 特權。
下面的命令顯示與 shell 相關聯的特權：
$ lssecattr -p $$
282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=
編輯 /etc/hosts 文件
$ lssecattr -f /etc/hosts
"/etc/hosts" does not exist in the privileged file database.
這不是特權文件。
因此，具有 DAC 訪問權的用戶應該能夠編輯這個文件。
$ ls -l /etc/hosts
-rw-rw-r-- 1 root system 1962 Mar 3 16:35 /etc/hosts
DAC 說明，除了 root 用戶和屬於 system 組的用戶之外，其他用戶對此文件沒有寫訪問權。
$ lssecattr -p $$
282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=
因此，在這裡按照 DAC 訪問權處理，只允許非 root 用戶有 READ 權限。
編輯 /etc/environment 文件
$ lssecattr -f /etc/environment
/etc/environment writeauths=aix.security.user
這是特權文件。
$ ls -l /etc/environment
-r--r--r-- 1 root system 1907 Mar 12 22:45 /etc/environment
DAC 訪問權限說明沒有用戶具有 WRITE 權限。
$ lssecattr -p $$
282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=
shell 進程具有 root 特權，但是用來訪問這個文件的 vi 命令不是特權命令。
這意味著，即使用戶有編輯這個文件所需的授權，aix.security.user，vi 也無法訪問文件。
$ lssecattr -c 'which vi'
/usr/bin/vi does not exist in the privileged command database.
編輯 /etc/environment 文件需要什麼？
(i) 用戶有所需的授權 aix.security.user
(ii) 正在執行的 shell 有所需的特權
(iii) 訪問此文件的命令有所需的特權
對於這種情況，AIX 提供 vi 編輯器的特權版本 pvi，它具有讀寫此文件的特權。
$ lssecattr -c 'which pvi'
/usr/bin/pvi accessauths=ALLOW_ALL innateprivs=PV_PROC_PRIV,PV_DAC_R,PV_DAC_W,
PV_DAC_X,PV_DAC_O
特權命令具有以下屬性：accessauths、innateprivs、authprivs、inheritprivs
特權文件具有以下屬性：readauths 和 writeauths
特權設備具有以下屬性：readprivs 和 writeprivs
結束語
本文通過示例和場景解釋了 RBAC 特性。我希望本文能夠幫助您更好地了解 AIX 高級特性 RBAC 和 MLS。
表 3. RBAC 經驗規則
- DAC 授權 角色 特權 說明 文件，命令，設備 YES NO NO NO 按照 DAC 權限。 文件，命令，設備 YES YES YES NO 按照 DAC 權限。 文件，命令，設備 YES YES YES YES 有授權的用戶優先執行特權操作。繞過 DAC。分配單一用戶責任。
單一用戶無法破壞系統。
可以禁用 root 訪問權。
