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

核心提示：用户定义的角色在这个部分中，我们将介绍用户定义的角色，基于角色的访问控制，第 2 部分，对用户定义的角色进行规划正如我们在第 1 部分“RBAC 中的预定义角色”中所讨论的，AIX V6 中包括三种预定义角色，在将设备包括到特权设备数据库中之前，必须对需要访问该设备的命令和应用程序进行全面的分析

用户定义的角色

在这个部分中，我们将介绍用户定义的角色。

对用户定义的角色进行规划

正如我们在第 1 部分“RBAC 中的预定义角色”中所讨论的，AIX V6 中包括三种预定义角色。这些预定义角色为划分管理职责提供了一种建议的方法。

可以对这些预定义角色进行修改或者删除，对于不同的环境，也可以创建一些合适的、新的角色。

注意：ISSO、SA 和 SO 角色由 Trusted AIX 使用。如果您的环境中包括 Trusted AIX，那么您可能会希望通过使用用户定义的角色来自定义您的 RBAC 环境。

尽管这些预定义角色适用于各种管理需求，但有时候，需要对职责进行进一步、更细粒度地划分。在这种情况下，增强的 RBAC 允许创建用户定义的角色。

在创建用户定义的角色时，应该考虑下面的几个要点：

角色的名称

角色的名称应该包括某些描述、或者对该角色功能的见解。角色名称限制为不超过 63 个可打印的字符。

授权

考虑应该向该角色分配哪些授权。

子角色

考虑该角色是否应该包含子角色。子角色是一种非常方便的方法，用于为用户定义的角色分配一个或者多个预先存在的角色。

身份验证

在通过 swrole 命令使用角色的时候，用户是否必须进行身份验证。

创建一个用户定义的角色

AIX V6 中包括下面的几种角色和 KST 管理命令：

mkrole

创建一个新的角色。当系统运行于增强的 RBAC 模式时，可以立即将角色数据库中创建的角色分配给用户，但出于安全的考虑，应该在通过 setkst 命令将数据库发送到内核安全表 (KST) 之后再使用这些角色。

rmrole

删除一个现有的角色。当系统运行于增强的 RBAC 模式时，从角色数据库中删除的角色将仍然存在于 KST 中，直到使用 setkst 命令更新 KST。

lsrole

lsrole 命令用于列出角色数据库中可供使用的角色定义。当系统运行于增强的 RBAC 模式时，出于系统安全的考虑，角色数据库中的信息可能与 KST 中的信息有所不同。要查看 KST 中角色数据库的状态，可以使用 lskst 命令。

chrole

更改或者修改一个现有的角色。当系统运行于增强的 RBAC 模式时，出于安全的考虑，在通过 setkst 命令将角色数据库发送到 KST 之前，对数据库所做的修改将不能使用。

swrole

swrole 命令可用于激活一个角色。激活一个角色也称为“交换”角色。用户只能激活已经分配给他的那些角色。

setkst

更新增强的 RBAC 内核安全表。

RBAC 安全检查在内核级执行，因此如果对 RBAC 安全数据库进行了任何用户级更改，那么在将这些更改用于 RBAC 安全检查之前，需要将它们更新到 KST 中。

lskst

列出内核安全表的内容。RBAC 安全数据库的内容与 KST 并不是始终相匹配的，因此 lskst 命令可用于列出、或者比较 KST 和用户级 RBAC 安全数据库。

在前面的部分中，我们为 oper1 分配了 so 角色。这个 so 角色允许 oper1 用户执行 shutdown 和 reboot 命令，除此之外，还允许执行其他几个特权命令，包括 kill 命令。

可以考虑下面这个场景：在执行了一次审核之后，安全控制人员请求我们限制 oper1 用户的权限，以便他只能执行 shutdown 和 reboot 命令，而不能执行其他的特权命令。因为不存在任何仅包括这两个命令的预定义角色，所以我们必须创建一个用户定义的角色。

要创建用户定义的角色，请遵循下面的步骤：

1. 以 root 或者角色管理用户的身份登录。

我们将使用 smitty mkrole 快速路径。

此时将显示下面的条目字段：

角色名 (Role Name)

这是用户定义的角色将使用的名称。

这个用户定义的角色将用于执行关闭和重新启动操作，因此我们将其名称定义为 shutdown_reboot。

角色 ID (Role ID)

唯一的角色标识编号。如果将其保留为空白，那么将分配下一个可用的角色编号。建议的方法是，使用下一个可用的角色编号。

授权 (Authorizations)

应该分配给该角色的授权。

这些授权可能是系统定义的、或者用户定义的授权。

在第 1 部分中，我们已经确定了所需的授权是 aix.system.boot.shutdown 和 aix.system.boot.shutdown。通过使用 F4 键，可以从授权列表中选择这两个授权。

角色列表 (Role List)

如果需要的话，为该角色添加的子角色列表。

组 (Groups)

如果需要的话，分配该角色的组列表。

SMIT 屏幕 (SMIT Screens)

定义这个角色可以访问的 SMITTY 屏幕。“*”通配符用于定义所有的屏幕 (ALL)。

可见性 (Visibility)

指定角色对系统的可见性状态。

描述 (Description)

角色的描述。

图 1 smitty mkrole 命令

在输入了 SMIT 屏幕中的各个字段条目之后，选择 Enter。

除了使用 SMIT 屏幕之外，另一种方法是使用 mkrole 命令。

图 2 显示使用与图 1 中相同的输入参数的 mkrole 命令。

图 2 mkrole 命令

2. 现在已经定义了用户定义的角色 shutdown_reboot。

在图 3 中，我们使用 lsrole 命令列出 shutdown_reboot 角色。

该角色仅包含 aix.system.boot.reboot 和 aix.system.boot.shutdown 两种授权。

通过限制可用于这个角色的授权，我们可以执行最少特权原则，为 oper1 用户授予适当的权限，使该用户只能访问完成其工作职能所需的那些命令。

图 3 lsrole——列出用户定义的角色

3. 为用户分配角色。

可以使用 chuser 命令分配 RBAC 角色。

图 4 显示在将 shutdown_reboot 角色分配给 oper1 用户之前，lsuser 命令的输出。现在，已经为 oper1 用户分配了 so 角色。

图 4 对定义了 so 角色的用户 oper1 执行 lsuser 命令

chuser 命令并不能为现有的角色追加新的角色。如果已经为 oper1 用户分配了现有的角色，那么 chuser 命令的新角色值中需要包括这些现有的角色。

图 5 显示使用 chuser 命令将 shutdown_reboot 角色添加到 oper1 用户。

图 5 使用 chuser 命令将 shutdown_reboot 角色分配给 oper1 用户

4. 更新内核安全表。

当运行于增强的 RBAC 模式时，将在 AIX 内核中执行授权和权限检查。如果对 RBAC 角色表进行了添加或者修改，那么在这些修改生效之前，需要将 RBAC 安全数据库更新到 AIX 内核中。

AIX V6 和增强的 RBAC 引入了 setkst 命令，以便将 RBAC 表更新到 AIX 内核中。

setkst 命令将读取 RBAC 安全数据库文件，并将其中的信息加载到内核安全表 (KST) 中。在缺省情况下，会将所有的安全数据库发送到 KST。

图 6 显示在使用 setkst 命令将 RBAC 安全数据库文件更新到 KST 中之前，oper1 用户执行 rolelist 命令的情况。

图 6 在没有更新 KST 的情况下使用 rolelist 命令

尽管已经向 RBAC 安全数据库定义了用户定义的角色 shutdown_reboot，但在新的角色定义之后，还没有使用 setkst 命令对 KST 进行更新。根据位于 KST 中的 RBAC 安全信息执行所有的 RBAC 安全检查，所以安全检查将会失败，这是因为 KST 中尚未包含 shutdown_reboot 角色。

执行 setkst 命令，将 RBAC 安全数据库更新到 KST 中。

setkst 还将对 RBAC 安全数据库表进行有效性检查。如果碰到错误，根据错误的严重程度，setkst 命令将列出错误并继续运行、或者在不更新 KST 的情况下退出程序。

图 7 显示 setkst 命令。在成功完成 setkst 命令之后，已经对 KST 进行了更新，并且新创建的角色将可供使用。

图 7 setkst 命令

注意：在将角色分配给用户之后，可能没有对 KST 进行更新。在对 KST 进行更新之前，用户将不能使用该角色。

5. 激活该角色。

在缺省情况下，直到用户登录系统并使用 swrole 命令激活角色，该角色才处于活动状态。如果 oper1 用户希望在不激活 shutdown_reboot 角色的情况下执行 shutdown 命令，那么 shutdown 命令将试图以 oper1 用户进行执行。

要激活一个角色，我们可以使用 swrole 命令。

swrole 命令将启动一个新的角色会话 Shell，该角色会话 Shell 需要用户使用他们的密码进行身份验证。

在对密码进行了身份验证之后，将激活该角色，并且将为该角色定义的授权中所包含的命令作为特权命令来执行。

在图 8 中，我们执行了 swrole 命令。swrole 命令需要使用角色名称作为参数，因此我们执行了命令 swrole shutdown_reboot。这个操作将激活 shutdown_reboot 角色。

在激活了 shutdown_reboot 角色之后，就可以使用 rolelist -ea 命令来列出有效的角色和授权。

图 8 swrole 命令

6. 现在，oper1 用户的 so 角色已经处于活动状态，并且可以执行 shutdown 和 reboot 命令。

通过为用户 oper1 添加 shutdown_reboot 角色，我们可以在不访问 root 用户或者成为 shutdown 组成员的情况下，执行 shutdown 和 reboot 程序。此外，不需要更改文件对象 DAC。

在图 9 中，我们以 oper1 用户执行 shutdown 命令。

图 9 以 oper1 用户执行 shutdown 命令

系统定义的和用户定义的授权

在这个部分中，我们将讨论增强的 RBAC 授权，并概括和描述创建用户定义的授权所需的过程。

对用户定义的授权进行规划

AIX 5L 的 RBAC 实现提供了两种类型的授权：

系统定义的授权——预定义的、并且作为 AIX 5L 安装过程的一部分而进行安装的授权。系统定义的授权是不能进行修改的。

用户定义的授权——不属于系统定义的授权的任何授权。在创建用户定义的授权之后，可以对其进行修改或者删除。

在授权层次结构中，系统定义的授权都使用“aix.”名称作为前缀。系统定义的授权不能进行修改或者删除。在系统定义的授权层次结构中，不能包括用户定义的授权。对于这种情况的说明，请参见下面的图 10。

图 10 授权命名约定

用户可以定义他们自己的授权层次结构，并将其分配给不同的角色。

这种层次结构的基本名称必须是除“aix”以外的其他名称。

用户定义的授权支持与系统定义的授权使用相同的层次结构概念。

在创建用户定义的授权时，应该考虑下面的几点限制：

用户定义的授权必须在新的顶层父节点之下进行定义。不能在现有的“aix.”层次结构之下创建用户定义的授权。用户定义的授权可以不是系统定义的“aix.”层次结构的子节点。

一个授权名最多可以由 63 个可打印的字符组成，但其中不允许使用空格。

一个授权最多可以具有 8 个父层次。

一个授权可以具有任意多个直接子节点，但是只能具有一个直接父节点。两个独立的授权不能具有相同的直接子节点。

在创建用户定义的授权时，应该考虑将要使用的命名约定。授权的名称应该包括某些描述、或者对该授权用途的理解。

在创建用户定义的授权时，建议使用下面的语法：

vendor_name.product_name.function.function1.function2…

表 1 进一步说明了在创建用户定义的授权时，建议使用的命名格式。

表 1 为用户定义的授权进行命名的建议语法

供应商名称	标识生产或者提供这个软件模块的供应商的名称。
产品名称	简要的产品名称。
功能、功能 1、功能 2……	这些字符串用于表示使用 RBAC 进行管理的功能。另外， 在定义这些字符串的时候，它们提供了一种层次结构的表示形式，以表现这些功能的组织方式。

ibm.tsm.managment.admin.stgpool 就是这种命名约定的一个示例。

可以潜在地创建这个用户定义的授权，以表示 IBM Tivoli® Storage Manager 存储池设备类别的管理方面的内容。

使用这样的格式，将有助于避免在多个软件组件之间出现授权命名的冲突。此外，这种格式还可以提供对授权用途的理解。

当创建用户定义的授权时，应该考虑下面的几个要点：

是否存在某种现有的系统定义的授权，其中包括了合适的特权命令？如果存在，那么应该考虑使用这个现有的授权是否符合最少特权原则。

新的授权是否属于某个现有的用户定义的授权层次结构、或者它是否为一个新的层次结构中的第一个授权？

如果该授权需要一个新的层次结构，那么该结构的格式应该是什么样的呢？

在创建授权的时候，应该指定授权 ID 吗？建议允许 mkauth 命令生成授权 ID。

创建用户定义的授权

在这个部分中，我们将创建一个名为 operatorPVI 的用户定义的授权。

稍后，oper1 用户将使用这个授权来管理特权文件。

我们还将创建一个名为 operator_pvi 的用户定义的角色，并将 operatorPVI 授权分配给 operator_pvi 角色。

提示：在这个示例中，我们只需要为 oper1 用户创建一个授权，因此不需要使用层次结构的授权树。如果多个用户需要不同的 PVI 管理授权，那么创建层次结构的授权（如 ibm.pvi.operator.oper1）可能更合适一些。

AIX Version 6.1 中包括下面几个授权管理命令：

mkauth

mkauth 命令可以创建一个新的用户定义的授权。在创建新的授权之前，所指定的授权名称中的所有父元素都必须已经存在于授权数据库中。

当系统运行于增强的 RBAC 模式时，可以将在授权数据库中创建的授权立即分配给角色，但是在对内核安全表进行更新之前，这些授权将不会生效。

rmauth

rmauth 命令用于删除用户定义的授权。rmauth 命令将仅删除授权数据库中现有的用户定义的授权。不能使用这个命令删除系统定义的授权。当系统运行于增强的 RBAC 模式时，出于安全的考虑，在通过 setkst 命令将授权数据库发送到内核安全表之前，对该数据库所做的修改将无法使用。

lsauth

显示用户或者系统定义的授权的属性。

chauth

用于修改现有用户定义的授权的属性。系统定义的授权是不能进行修改的。当系统运行于增强的 RBAC 模式时，出于安全的考虑，在没有通过 setkst 命令将数据库发送到内核安全表之前，对数据库所做的修改将无法使用。

要创建 operatorPVI 用户定义授权，请遵循下面的操作：

1. 以 root 用户或者授权管理用户的身份登录。

图 11 显示 mkauth 命令。在这个示例中，我们允许由系统生成 ID，并使用 dfltmsg 节中的 Operator PVI 管理描述。

图 11 mkauth 命令

2. 创建 operator_pvi 角色，并分配 operator_pvi 授权。

在创建了 operator_pvi 角色之后，我们可以显示该角色，并确定为该角色分配哪些授权。在这个示例中，我们只分配了 operatorPVI 授权。

图 12 显示 mkrole 和 lsrole 命令。

图 12 mkrole 命令

3. 为用户分配角色。

可以使用 chuser 命令分配 RBAC 角色。

chuser 命令并不能为现有的角色追加新的角色。因为已经为 oper1 用户分配了现有的角色，所以 chuser 命令的新角色值中需要包括这个现有的角色。

4. 使用 setkst 命令更新 KST。

图 14 显示 setkst 命令

如果希望将 operatorPVI 授权用于某些特权命令，那么现在可以将这些特权命令分配给该授权。因为 operatorPVI 授权将用于特权文件访问，所以不需要为该授权分配任何特权命令。

特权命令数据库

这个部分将介绍增强的 RBAC 权限和进程权限集。

权限

权限是一种这样的机制，它用于在系统调用中为一个进程授予扩充的功能。权限可用于确定命令是否符合执行某项操作的条件。

权限和授权之间的定义区别在于，权限是与特定的进程相关联的，而授权则是通过角色与用户相关联的。

权限的概念适用于大部分的内核级构造，因为定义和大部分的检查都是发生在内核级构造中的。为各种命令、设备和进程分配相应的权限，这些操作都是在内核之外执行的，然后使用 setkst 命令更新到内核中。

AIX 将权限定义为位掩码的各个位，以此执行对特权操作的访问控制。AIX V6 中附带了 100 多种权限，为特权操作提供了非常细粒度的控制。

通过特权命令数据库，可以为命令调用分配相应的权限；通过特权设备数据库，可以使用权限来控制对设备的访问。

在为系统调用确定访问权限时，内核将检查该进程是否具有所需的相关权限位，然后为其授予相应的权限、或者拒绝执行。

AIX V6 中的权限是预定义的，并且不能够对其进行修改、删除或者创建。

权限（与授权一样）采用了分层结构。所有的权限都以“PV_”前缀开头，这是权限位的一种文本表示形式。内核采用层次的方式执行权限检查。在检查权限的时候，系统将首先检查该进程是否具有所需的最少权限，然后按层次结构继续进行，检查是否存在功能更强大的权限。

PV_ROOT 权限是一种特殊的权限，它代表了除 PV_SU_ 之外所有权限的父节点。分配了 PV_ROOT 权限的进程在执行时就如同已经对其分配了系统中除 PV_SU_ 之外的所有权限。

进程权限集

进程权限集用于动态地约束或者限制特权操作。内核中定义了多个权限集，以便为特权操作提供各种控制。多个权限集允许操作系统实施动态权限控制，并且允许应用程序实现最少特权原则。

不同的权限通过下面的权限集与进程相关联。

限制权限集

限制权限集（Limiting Privilege Set，LPS）可以为给定进程定义权限的最大限制或者硬限制。

LPS 定义了最大的权限提升；使用系统中定义的任何接口，进程都不可能获得比这个值更多的权限。此时，将进程限制为 LPS 权限。

这也意味着，其余的权限集将始终是 LPS 的子集。

尽管 LPS 是最大限制或者硬限制，并且不允许超过这个限制，但是每个进程都可以减少 LPS 中的权限。一旦某个进程减少了 LPS 中的权限，那么这个新的、经过减少的限制将成为新的 LPS，并且不能扩展或者增加到其原始值。

通过降低 LPS，允许进程根据相关的权限来限定相应的界限。例如，进程可以在执行用户提供的自定义程序之前减少 LPS 中的权限。

在缺省情况下，进程的 LPS 中包含系统中可供使用的所有权限。

最大权限集

最大权限集（Maximum Privilege Set，MPS）是某个进程可以使用的所有权限的集合。MPS 可以包括 LPS 中的任何权限，但不能超出 LPS。

MPS 并不是一成不变的，并且仅在 LPS 的限制之内具有硬限制。

因此，在一个进程的生存期内，MPS 的值是可以更改的。

下面提供了一些示例，说明了在什么情况下可以更改 MPS：

在当前进程执行另一个特权命令，然后获得相关的附加权限的时候。

如果该进程具有适当的权限，那么它可以以编程的方式动态地扩展 MPS。

有效权限集

有效权限集（Effective Privilege Set，EPS）是某个进程当前处于活动状态的权限的列表。EPS 始终是该进程的 MPS 的子集，并且在执行特权操作时，内核将使用 EPS 进行访问权限检查。EPS 并不是一成不变的，并且可以由进程对其进行控制。EPS 可以与 MPS 相等，但不能超出 MPS。

进程可以执行 EPS 的动态控制，以执行最少特权原则。

可继承的权限集

可继承的权限集（Inheritable Privilege Set，EPS）定义了从父进程传递到子进程的 MPS 和 EPS 的权限。

IPS 可以包括 LPS 中的任何权限，但是不能超出 LPS。

可以采用下面的方式，在进程中设置 IPS：

如果该进程具有适当的权限，那么它可以以编程的方式，通过 setppriv() 系统调用来扩展 IPS。

在执行某个特权命令时，将与该命令相关联的 inheritprivs 属性中指定的权限分配给 IPS。

使用过的权限集

使用过的权限集（Used Privilege Set，UPS）描述在进程的生存期内曾用于访问检查的权限。UPS 可用于确定该进程所需的权限。

无论内核何时检查一个进程是否具有给定的权限，它都将会在该权限的 UPS 中存储一个成功的检查。

工作负载分区权限集（Workload Partition Privilege Set，WPS）

可以将一个系统 WPAR 配置为限制全局环境中允许的特权操作。可以通过 WPS 对系统 WPAR 中允许的特权操作进行控制。

全局环境的 root 可以使用 WPS 将有限的权限集分配给 WPAR。可以在 /etc/wpar/secattrs 配置文件中、或者在启动 WPAR 期间使用 startwpar 命令指定 WPS。WPAR 中运行的所有进程都将使它们的 LPS 与它们的 WPS 相等。

图 15 显示增强的 RABAC 权限集的图形表示形式。

图 15 增强的 RBAC 权限集

增强的 RBAC 提供了下面的命令，以便管理各种权限集：

lssectattr

lssecattr 命令用于列出一个或者多个命令、设备或者进程的安全属性。lssecattr 可用于列出活动进程的 LPS、MPS、EPS、IPS 和 UPS。

setsecattr

setsecattr 命令可以设置命令、设备或者进程的安全属性。setsecattr 命令可用于修改活动进程的 LPS、MPS、EPS 和 IPS。不能使用 setsecattr 命令修改 UPS，因为 UPS 是一个只读属性。

特权命令

如前所述，AIX 的命令授权通常依赖于 DAC、或者依赖于直接包括于命令代码中的授权。

增强的 RBAC 利用授权、角色和权限，以提供更细粒度的安全控制方法。

增强的 RBAC 模式提供了一种框架，以便在不需要对系统中可执行文件进行更改、或者对 DAC 权限进行修改的情况下，执行授权检查，并通过特权命令数据库授予相关的权限。

特权命令数据库允许管理员为命令授予用户访问权限和相关权限，否则，它们将不能执行、或者没有合适的权限来执行相应的任务。特权命令数据库用于保存特定命令的授权信息，以及在授权检查成功的情况下为进程授予的权限。

当特权命令数据库存储在本地时，它位于 /etc/security/privcmd 文件中，并采用命令及其安全属性的形式包含相关的信息节。

下面是特权命令数据库中的一些重要属性：

accessauths

保护命令执行的访问授权列表。如果用户具有该列表中的任何一个授权，那么将允许其执行相应的命令，并且执行其中包含的某些或者所有特权操作。

innateprivs

固有权限是在调用者成功地进行了访问授权检查的情况下，分配给进程的权限。

authprivs

授权权限是在调用者具有相关授权的情况下，分配给进程的附加权限。这个属性为命令提供了更细粒度的控制，它允许一组受限的用户执行附加的特权操作。

inheritprivs

可继承的权限是该进程将传递给其子进程的权限。

secflags

安全标志的列表。

当增强的 RBAC 模式系统中的用户尝试执行某个命令时，首先将在特权命令数据库中查找该命令。

如果数据库中存在该命令，那么将根据与用户会话相关联的授权，以及被调用命令的 accessauths 属性值执行检查。如果该会话具有所列出的某个授权，那么将允许这个用户执行该命令，而无论这个用户是否通过该命令的 DAC 执行检查。

图 16 显示增强的 RBAC 命令执行过程的图形表示形式。

图 16 增强的 RBAC 命令执行

如果一个命令包含于特权命令数据库中，那么它将作为一个 RBAC 特权命令。如果一个程序使用了 setuid，并且该程序没有在特权命令数据库中列出，那么它仍然可能分类为特权的，但不能称为 RBAC 特权命令。

如果一个命令在特权命令数据库中没有任何条目，那么它不是 RBAC 特权命令，并且对它的访问由 DAC 和该命令本身来执行。

如果一个命令包含于特权命令数据库中，但是调用者的会话不具有允许执行该命令的授权，那么在 DAC 和 UID/GUID 检查成功的情况下，将仍然允许执行该命令。

特权文件数据库

在这个部分中，我们将介绍特权文件数据库和 pvi 命令。

使用 DAC 的特权文件管理

通常在 AIX 5L 中，许多系统配置文件都由 root 用户所有，并且利用 DAC 文件权限设置来防止一般用户对系统配置文件进行修改。

某些系统配置文件使用了命令接口，以便允许对其进行修改和管理。/etc/inittab 文件使用了 DAC，以便只允许 root 用户对该文件进行写访问。如果需要由 root 用户以外的其他用户对该文件进行更新，那么可以使用 RBAC 创建一个角色/授权，以便允许执行 inittab 管理命令集，包括由 root 用户以外的其他用户执行的 chitab、rmitab、lsitab 和 mkitab。

在 AIX 5L 中，并不是所有的系统配置文件都提供了命令接口以实现对文件的修改。需要为这些文件提供一种工具，允许具有合适授权的管理员直接编辑和保存文件（否则，他们将不能访问该文件）。

使用 RBAC 的特权文件管理

特权文件数据库中包含被管理员定义为需要特权授权的文件的列表。当在本地进行存储时，特权文件数据库位于 /etc/security/privfiles 文件中。特权文件数据库将特权文件映射为对其进行查看或修改所需的授权。

pvi 命令使用特权文件数据库来确定任何特权文件的名称和授权模式。

特权文件可能包括不使用单独的命令接口的任何系统配置文件、以及管理员希望对其进行访问限制的其他文件。

特权文件数据库使用 RBAC 授权作为一种授权或者限制文件访问的方法。

特权文件数据库中所包含的文件应该与相同的 tvi（受信任的 vi，trusted vi）命令一致，并且对 tvi 或者 vi 命令来说，应该是可读的文件。

注意事项：在将文件添加到特权文件数据库之前，该文件必须已经存在。不能使用 pvi 命令创建一个新的文件。

特权文件数据库的限制

特权文件数据库执行下面的限制：

tvi 命令现有的所有限制都保留于 pvi 命令中。

系统必须运行于增强的 RBAC 模式中。

在通过特权文件数据库对其进行管理时，该文件必须已经存在。不能使用 pvi 命令创建文件。

只有特权文件数据库中所包含的文件才可以由 pvi 命令进行编辑。

pvi 命令一次只允许打开一个文件。

pvi 命令无法使用与文件打开时不同的名称保存该文件。

不能使用 pvi 命令来编辑特权文件数据库。

使用 pvi 命令只能打开常规文件。不能使用 pvi 命令打开文件链接。

pvi 命令不支持用户定义的宏。

特权文件数据库仅支持读授权 (readauth) 和写授权 (writeauth)。

在授予 writeauth 权限时，其中隐含了 readauth，但是该授权将不会更新到 /etc/security/privfiles 文件的 readauth 节中。

向特权文件数据库添加一个文件

安全控制人员请求我们允许给予 oper1 用户对 /etc/hosts 文件的读/写访问权限。我们将创建一个用户定义的角色和授权，然后将 /etc/hosts 文件添加到特权文件数据库，从而允许 oper1 用户对 /etc/hosts 文件进行读写操作。

/etc/hosts 文件具有相应的 DAC 权限，允许 oper1 用户和 root 用户以外的其他所有用户或者 system 组的成员对其进行只读访问。

图 17 /etc/hosts 文件的 DAC 权限

要向特权文件数据库中添加一个文件，请执行下面的步骤：

1. 创建或者确定将用于特权文件访问的授权和角色。

特权文件数据库使用 RBAC 授权，以便对文件的读写访问控制进行身份验证。

对于要添加到特权文件数据库中的文件，管理员必须了解以下内容：

文件名称。

读授权 (readauth) 的 RBAC 授权。如果指定了 writeauth，readauth 则不是强制的。readauth 可以指定为一个授权列表。

写授权 (writeauth) 的 RBAC 授权，如果需要的话。writeauth 可以指定为一个授权列表。

在这个示例中，我们将使用先前在“用户定义的角色”中创建的 operatorPVI 授权和 operator_pvi 角色。

2. 使用 setsecattr 命令，我们将 /etc/hosts 文件添加到特权文件数据库。

我们将为 operatorPVI 授权定义对 /etc/hosts 文件的写访问权限。

在图 30 中，我们使用 setsecattr 命令将 /etc/hosts 文件添加到特权文件数据库中，并允许授予 operatorPVI 对该文件的写访问权限。对 /etc/hosts 文件的写访问权限 (writeauth) 还支持对该文件的读访问权限 (readauth)。

图 18 setesattr 命令

3. 使用 setkst 命令更新内核安全表。

如果 oper1 用户试图在不更新 KST 的情况下使用 pvi 命令，那么 pvi 命令将会失败，因为 KST 中的安全检查将无法找到 oper1 用户的 readauth 或者 writeauth 的有效条目。

图 19 显示 oper1 用户在更新 KST 之前执行 pvi 命令。

图 19 在更新了 KST 的情况下使用 pvi 命令访问 /etc/hosts 文件

4. oper1 用户现在可以使用 pvi 命令对 /etc/hosts 文件进行读写操作。

如果 oper1 用户试图使用 vi 命令修改和保存 /etc/hosts 文件，那么将使用 /etc/hosts DAC 文件权限以确定 oper1 用户是否具有适当的权限，以保存对该文件的更改。

oper1 用户不具有对 /etc/hosts 文件进行写访问的 DAC 权限，因此保存 /etc/hosts 文件的尝试将无法成功。

图 20 显示 oper1 用户使用 vi 命令编辑 /etc/hosts 文件。可以查看该文件，但不能保存数据，因为 DAC 文件权限只允许用户 oper1 进行读访问。

图 20 用户 oper1 使用 vi 命令编辑 /etc/hosts 文件

当使用 pvi 命令编辑 /etc/hosts 文件的时候，其结果是不同的。

当使用 pvi 命令的时候，用户 oper1 可以修改并保存 /etc/hosts 文件。

图 21 显示 oper1 用户使用 pvi 命令编辑 /etc/hosts 文件。可以查看、修改和保存该文件。即使 DAC 文件

权限只允许用户 oper1 进行读访问。

图 21 用户 oper1 使用 pvi 命令编辑 /etc/hosts 文件

特权设备数据库

这个部分将讨论特权设备数据库。

使用 RBAC 的特权设备管理

从概念上看，特权设备数据库与特权文件数据库非常类似，但特权设备数据库用于控制对设备的访问，而不是控制对文件的访问。

与通过传统的设备访问控制方法所管理的数据库相比，特权设备数据库可用于为数据库提供更好的访问控制。

当在本地存储该数据库时，它包含于 /etc/security/privdev 文件中。

特权设备数据库采用下面的属性，以存储对设备进行读写操作的特权信息：

readprivs

列出允许从设备进行读操作的权限。

在提出读请求以打开某个特权设备时，只有在 readprivs 中指定某个权限存在于该进程的有效权限集 (EPS) 中时，才允许打开设备。

writeprivs

列出允许对设备进行写操作的权限。

在提出写请求以打开某个特权设备时，只有在 writeprivs 中指定某个权限存在于该进程的有效权限集 (EPS) 中时，才允许打开设备。

可以使用 lssecattr 和 setsecattr 命令，将一个设备包括到特权设备数据库中。

在将设备包括到特权设备数据库中之前，必须对需要访问该设备的命令和应用程序进行全面的分析，以确保指定了适当的权限。