了解 AIX 高级特性: 简便的基于角色的访问控制

核心提示：简介过去，由单一用户（root 用户）控制系统的安全机制，了解 AIX 高级特性: 简便的基于角色的访问控制，root 用户决定谁可以登录、谁可以访问数据、哪些进程有权进入内核模式等，但是，分配单一用户责任， 单一用户无法破坏系统，单一 root 用户的缺点是，如果未经授权的人控制了根用户

简介

过去，由单一用户（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	建立和维护安全策略 为用户设置密码 网络配置 设备配置
SO	SO	系统关机和重新引导 文件系统备份、恢复和限额 系统错误日志记录、跟踪和统计 工作负载管理
SA	SA	用户管理，不包括密码 文件系统管理 软件安装和更新 网络守护进程管理和设备分配

命令和示例

下表给出一些命令的详细信息，帮助您了解如何使用授权和角色。

表 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) 使用 setkst 更新内核表
与激活角色相关的操作	rolelist -a [检查与登录会话的用户相关联的角色] swrole (role_name) [切换以激活角色] rolelist -e [检查会话中哪个角色是激活的]

请通过以下示例了解这些命令：

如何作为 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 访问权。