基于角色的访问控制，第 3 部分

核心提示：保护 root 用户的安全下面的部分将介绍在增强的 RBAC 模式中运行时如何禁用 root 用户，选择保护 root 用户的安全当 AIX 系统运行于增强的 RBAC 模式时，基于角色的访问控制，第 3 部分，可以对系统进行相应的配置，从而使 root 用户不具有超级用户权限，其中没有定义也无法列出该角色，lsrol

保护 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 数据库搜索。