分类：
2008-05-10 22:15:54
2008 年 1 月 21 日
在本系列文章中，我们将向您陆续介绍并和您一起讨论基于角色的访问控制（Role Based Access Control）的相关内容。作为 AIX 6 的安全新特性，RBAC 为用户提供了细颗粒度的，更加灵活的安全管理方法。本文是摘自 IBM 红皮书《AIX V6 Advanced Security Features Introduction and Configuration》。
|
AIX V6 引入了增强 RBAC，即向一个或者多个普通用户帐户委派角色和授权的方法。
RBAC 允许系统管理员将某些任务委派给普通用户，而传统的做法是，这些任务由 root 用户，或者通过 setuid/setgid 执行。
RBAC 的优点之一是，通过限制分配给某个命令的权限（仅为命令分配执行其任务所必需的权限），可以尽可能地减少 setuid/setgid 程序的使用。
AIX V6 中没有提供遗留或者增强模式 RBAC 的特定安装包。大多数增强 RBAC 命令都包含在 bos.rte.security 文件集中。
下面的部分将对增强 RBAC 中所包括的组件进行介绍和深入地讨论。
|
这里，我们将介绍传统的 AIX 管理方法，以及用于该目的的一些工具。
在 AIX 操作系统中，传统的特权管理方法依赖于名为 root 的单个系统管理员帐户。我们将 root 帐户作为超级用户，这是因为 root 用户帐户有权执行 AIX 系统中所有特权的系统管理任务。通常将 root 用户的用户标识/uid 指定为 0。
仅依赖单个超级用户来完成系统管理中各方面的操作，将在管理职责分离方面产生一些问题。尽管在某些业务环境中，可以仅使用一个管理帐户，但很多环境都需要多个管理员，其中各个管理员负责执行不同的任务。
如果仅使用一个管理帐户，那么就可能需要在两个或者更多系统管理员之间共享使用超级用户的角色。在某些环境中，需要将所有特权的系统管理任务集中于一个单独的个体，那么这种共享的管理方法可能会破坏其中的业务审核指导原则。
共享超级用户角色的一种替代方法是，创建与 root 用户具有相同 UID 的另一个用户。
从安全的角度来说，无论采用这两种方式中的任何一种，都可能产生各种各样的问题，因为向每个管理员授予了系统的全部控制权限。没有办法限制任何给定的管理员所能够执行的操作。因为 root 用户是权限最高的用户，所以该用户可能执行未经授权的操作，还可以删除对这些活动的任何审核信息，因此要对其管理操作进行跟踪，几乎是不可能的。
自主访问控制 (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# |
如前所述，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 程序的适当授权。
在 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 中所包括的组件进行介绍。
在 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 提供了粒度更细的授权控制，并且减少了对 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 的内容。
在包括许多服务器的环境中，在一个集中的位置维护 RBAC 安全数据库，可能更为有效。在需要跨所有的系统实现和加强公共安全策略的企业环境中，情况也是如此。
当控制安全策略的 RBAC 安全数据库独立地存储于各个系统中时，安全策略的管理就成为了指定管理员的负担。
在 AIX V6 中，增强 RBAC 模式允许在 LDAP 中存储增强 RBAC 安全数据库。这允许为 LDAP 环境中所有的系统集中地管理安全策略。
AIX V6 中支持将所有的增强 RBAC 安全数据库放置于 LDAP 中，具体包括以下数据库：
局限性：存储在 LDAP 中的授权数据库将仅包含用户定义的授权。系统定义的授权无法存储在 LDAP 中，它们将保存在各个客户端系统的本地。
AIX V6 中所提供的各种实用工具允许管理员进行以下操作：
。
表 1 比较 RBAC 各种模式中可用的特性。
| 特性 | 遗留 RBAC 模式 | 增强 RBAC 模式 |
|---|---|---|
| 选择性的角色激活 |
在缺省情况下，所有的用户角色都是活动的。 | 在缺省情况下，所有的角色都是非活动的。可以使用 swrole 命令来使用相应的角色。 |
| default_roles 属性 | 否 | 是 |
| swrole 命令 | 否 | 是 |
| 角色管理命令 | 是 | 是 |
| 授权管理命令 | 是 | 是 |
| 授权层次结构 | 否 | 支持授权层次结构的概念 |
| 授权检查 |
仅当命令需要在执行时检查授权的情况下强制进行。 | 在执行时，通过特权命令数据库或者通过命令检查授权强制进行。 |
| 细粒度权限 | 是 | 是 |
| pvi 命令 | 否 | 是 |
| 内核安全表 | 否 | 是 |
| RBAC 数据库位置 | 本地文件 | 本地文件或者 LDAP |
表 2 显示了增强 RBAC 的大小限制。
| 描述 | 局限性 |
|---|---|
| 角色名称的最大长度 | 63 个可打印的字符 |
| 每个会话可以拥有的最大角色数目 | 8 |
| 授权名称的最大长度 | 63 个可打印的字符 |
| 授权层次结构中所允许的最大层次数目（包括顶层的父节点） | 9 |
| 每个命令可以拥有的访问授权的最大数目 | 8 |
| 每个命令可以拥有的最大授权特权集合 | 8 |
|
在这个部分中，我们将简要介绍如何在 AIX V6 中安装和配置 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 模式，那么可以通过将 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 |
当采用增强 RBAC 模式使用 RBAC 的时候，root 用户将继续生效（与以前的 AIX 5L 发行版中一样），并且可以保持其作为超级用户帐户的传统角色。
增强 RBAC 具有一个特性，即能够禁用 root 用户帐户，并通过一个或者多个用户帐户，执行所有的特权管理和命令。
在这个部分中，我们将讨论如何为用户添加一个预定义的角色。
随着 AIX V6 中增强 RBAC 的发布，在 RBAC 的缺省配置中包括了三个预定义的角色和几个子角色。
这三个预定义角色分别是：
SA 角色提供了日常的管理功能，并负责以下事项：
SO 角色提供了日常操作所需的功能，并负责以下事项：
这些预定义角色中的每一种角色都具有预配置的授权定义，并且如果需要的话，可以进行进一步自定义。
注意： Trusted AIX 将使用 ISSO 、 SA 和 SO 角色。如果您的环境中包括 Trusted AIX ，那么您可能会希望通过使用用户定义的角色来自定义您的 RBAC 环境。
正如在本部分中前面所讨论的，SO 预定义角色包括用以执行 reboot 和 shutdown 命令的授权。
如果我们不知道某个预定义角色是否包括 shutdown 和 reboot 命令，那么可以执行如下的过程：
1. 确定需要执行的特权命令。在这个示例中，需要执行的是 shutdown 和 reboot 命令。
将完全限定的特权命令添加到 smitty 菜单的条目字段区域，并选择 Enter 键。
2. 确定该特权命令是否包括在授权中。如果预定义的授权中没有包括该命令，那么可能需要定义一个用户定义的授权。
smit setsecattr_cmdmod 命令显示了 /usr/sbin/exec_shutdown 命令的授权为 aix.system.boot.shutdown。
使用相同的方法，我们可以确定 aix.system.boot.reboot 授权中定义了 /usr/sbin/reboot 命令。
此外，可以使用 lssecattr 命令，在不调用 smitty 菜单的情况下，获取相关的信息。
3. 确定是否存在某个合适的角色包括了该授权。如果预定义的角色中没有包括合适的角色，那么可能需要定义一个用户定义的角色。
lsrole 命令可用于列出各种已定义的角色。可以组合使用 lsrole 和 grep 命令，以确定是否为角色分配了某个授权。
图 5 显示了 SO 角色包含几种授权，其中包括 aix.system.boot.reboot 和 aix.system.boot.shutdown。
另一种选择是，使用 lsauth 命令和角色属性，以显示将某个授权所分配到的角色。
lsauth 命令可以与“*”通配符一起使用。可以在名称的末尾使用通配符，以列出整个层次结构。在通配符之前指定的整个字符串必须是一个有效的授权名称。
通过使用 lsrole 和 lsauth 命令的组合，我们可以确定授权所分配到的一个角色或者多个角色、以及分配给角色的授权。
4. 将角色分配给用户。
可以使用 chuser 命令来分配 RBAC 角色。
图 7 显示了在将 so 角色分配给 oper1 用户之前，lsuser 命令的输出。当前没有为 oper1 用户分配任何角色，
因此角色值为空。
chuser 命令并不会为现有的角色追加新的角色。如果已经为 oper1 用户分配了一些现有的角色，那么需要在 chuser 命令的新角色值中包含这些现有的角色。
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 程序。
要激活一个角色，可以使用 swrole 命令。
swrole 命令将启动一个新的 Shell，这个 Shell 需要用户使用他们的密码进行身份验证。
在对密码进行了身份验证之后，将激活该角色，并且将该角色所定义的授权中所包括的命令作为特权命令进行执行。
在图 10 中，我们执行了 swrole 命令。swrole 命令需要使用角色名作为参数，因此我们执行了 swrole so。这个操作将激活 so 角色。
一旦 so 角色处于活动状态，就可以使用 rolelist -ea 命令列出有效的角色和授权。
6. 现在，oper1 用户具有了处于活动状态的 so 角色，并且可以执行 shutdown 命令。
通过为用户 oper1 添加 so 角色，它允许该用户在不访问 root 用户或者成为 shutdown 组成员的情况下，执行 shutdown 和 reboot 程序。此外，不需要更改文件对象的 DAC。
在图 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 属性的值。
当最初使用 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 将对会话分配所有的用户角色。如果为用户分配了八个以上的角色，那么该会话只能启用前八个角色。
学习|
Brad Gough 是 IBM 悉尼全球服务部门的一名 AIX 技术工程师，他从1987年进入 IBM，最开是一名 RS/6000 的硬件工程师，2000年他转做 AIX 的支持工作，主要擅长于AIX，NIM和HACMP。他目前主要负责澳大利亚和新西兰地区的 P 系列主机的安装以及实施工作。他拥有多个 IBM 的 P 系列认证。 | ||
