3. 性能监控工具更新
由于 AIX 6.1 支持新的硬件和提供了新的特性,性能监控的工具也进行了相应的更新以反映新的数据。更新主要包括:
- topas/vmstat/iostat/netstat/nfsstat/filemon/svmon/netpmon/proctree/trace/curt/tprof/pprof 等命令更新,增加命令选项以支持从全局环境收集某个或所有 WPAR(工作负载分区)的性能状态数据,或者在 WPAR 内运行收集该 WPAR 的数据。
- iostat 命令支持获取磁带设备的 I/O 状态信息。
- topas 和 lparstat 命令升级支持获取 POWER 6 新的多个共享处理器池信息。
虚拟化
1. 工作负载分区(Workload Partitions)
AIX 6.1 在虚拟化方面的最大变化就是引入了 WPAR。WPAR 是纯软件的虚拟化解决方案,他与 IBM POWER 平台上传统的 LPAR(逻辑分区)方案有着本质上的不同,下表给出了 LPAR 和 WAPR 的简单比较,更多的内容会有专文进行阐述。
|
LPAR |
WPAR |
实现技术 |
硬件支持,POWER 处理器加 Hypervisor(微码内置功能) |
软件功能,由 AIX 内核实现 |
管理方法 |
HMC 或 IVM |
AIX 系统命令,WPAR Manager |
特点 |
一个服务器,多个物理或虚拟设备,多个 OS |
一个 OS,一套物理或虚拟设备,多个应用环境 |
操作系统 |
AIX 或者 Linux |
仅 AIX 6.1 |
成本 |
需要购买 APV |
随 AIX 6 附带,无额外费用。 WPAR Manager 需额外许可。 |
承载 WPAR 的 AIX 系统在 WPAR 的术语中称之为全局环境(Global Environment),它既可以运行在一个物理机器上,也可以是一个 LPAR。WPAR 相比于 LPAR 是更加轻量级的虚拟化解决方案,它与全局 AIX 环境共享处理器,内存,网络和文件系统资源,创建和初始化操作简单快捷。
WPAR 又分为系统 WPAR(System WAPR)和应用 WPAR(Application WPAR)两类。系统 WPAR 是一个完整的 AIX 环境,拥有独立的资源,如独立的 init 进程树提供网络服务,独立的文件系统,用户帐户等。创建系统 WPAR 的过程实际上包括了 AIX 软件包安装的过程。对于用户来讲,访问 WPAR 与其他独立的 AIX 系统差异不大,既可以登录到终端,可以使用 telnet 连接。而应用 WPAR 则是一个更加精简的环境,它只包含应用程序特定的进程和相应的内核支撑环境,它不包含自己独立的资源,只能共享使用全局环境的资源。当应用 WPAR 中包含的应用程序启动时,它也就启动,当应用停止时应用 WPAR 也就被删除了,因此从用户的角度来看它更加接近于传统的 chroot。
WPAR 为用户带来了以下好处:
- 进一步降低虚拟化成本。
- 优化系统资源使用率:一个系统中可以有多个 WPAR 运行,在隔离的同时也使得系统的计算资源得以更加充分的利用。
- 更细粒度的对计算资源进行分配:管理员可以对对 WPAR 的资源(处理器,内存等)占用进行控制,保证应用可以合作性的共享系统资源。
- 对应用环境的隔离进一步提高了安全性和稳定性:每个 WPAR 都是独立的环境,有自己的安全上下文和用户账号等,一个 WPAR 内的安全问题不会对其他 WPAR 和全局环境产生影响。
- 提高应用可用性:管理员可以对某个 WPAR 的状态生成快照(checkpointing)并稍后恢复运行(resuming)。此功能可以提高应用的可用性:当系统故障发生时,暂停应用,移动到另外的平台上恢复运行,同时对故障系统进行维修。
要注意的是,LPAR 和 WPAR 两者之间并不冲突,完全可以互补。
2.WPAR 动态应用迁移,使用 IBM Workload Partition Manager™
动态应用迁移(Live Application Mobility)是 AIX 6 WPAR 提供的一项高级特性,它允许 WPAR 动态的移动到另外一个系统上,而不影响其中应用的持续运行。该功能的关键特点在于:
- WPAR 在迁移时处于活动状态,无需停止其中的应用或者整个 WPAR。对于用户来讲,迁移时的影响只是 WPAR 中的应用响应速度有短暂的降低。
- 迁移可以在逻辑分区和物理机器之间进行,也就是说,WPAR 可以从同一个物理机器上一个逻辑分区迁移到另一个,也可以完全迁移到另外一个物理机器。当然,在不同的物理平台之间迁移时,必须要保证平台硬件的兼容性,例如处理器类型。
- 需要迁移的 WPAR 其文件系统必须放在 NFS 上,以保证在源和目的全局环境中都能够访问该 WPAR 的数据。迁移过程由 IBM Workload Partition Manager 软件进行控制。
Workload Partition Manager 是 IBM 单独销售的专用于 WPAR 管理的软件平台。它除了为 Live Application Mobility 提供支持外,还可以对 WPAR 进行创建,修改,删除,监控等管理操作,并支持对多台服务器实行集中式图形化管理。如果不使用 WPAR Manger,管理员只能够使用基本的命令行工具或者 SMIT 来管理 WPAR,因此即使不需要 Live Application Mobility 功能,也推荐使用 WPAR Manager 来降低 WPAR 管理的复杂度。
Live Application Mobility 可以被用来进一步提高灵活性和可用性。当平台需要进行升级,或者由于故障需要停机维护时,通过此功能可以将工作负载动态的切换到其他硬件上,在不影响应用的同时即可完成维护任务。
3.Live Partition Mobility 支持
Live Partition Mobility 是 IBM POWER 6 的平台提供的新一代虚拟化高级特性,它使得逻辑分区(LPAR)可以在物理系统之间动态迁移。与 WPAR 的 Live Application Mobility 类似,它也可以帮助提高应用的灵活性和可用性。
Live Partition Mobility 需要 POWER 6 硬件平台的支持,被迁移的 LPAR 内运行的操作系统也必须要支持此特性。IBM 在 AIX 6.1 和 5.3 TL7 中增加了对 Live Partition Mobility 的支持。
4. 支持多个共享处理器池(Multiple Shared Processor Pools)
多 个共享处理器池是 POWER 6 平台引入的虚拟化新特性。在 POWRE 5 平台上,所有的共享处理器(Shared Processor)逻辑分区(LPAR)都使用一个统一的、系统全局的处理器池(Processor Pool),并从中取得自己的处理器资源。POWER 6 对这一特性做了增强:一个物理系统中可以有多个处理器池,每个池可供一个或多个(即一组)LPAR 使用,并且处理器池中的处理器数量和 LPAR 数量都动态可调,这样可以按组来控制 LPAR 的处理器资源分配。AIX 6.1 和 AIX 5.3 TL7 系统的对这一特性提供了支持,并升级了性能工具以支持获取系统处理器池的信息。
可管理性
1.IBM Systems Director Console
IBM 为 AIX 用户提供了多种手段来执行 AIX 管理任务,每个管理员都可以选择自己习惯的方式以最高的效率来执行。AIX 5L 中提供的管理手段包括:
- 命令行。使用传统的 UNIX 世界的命令行程序,管理员能清楚的知道自己干了什么,并能深入的理解系统行为。但是学习难度较高,操作比较枯燥。
- SMIT 菜单,包括 ASCII 界面方式和基于 X-window 系统的 GUI 方式。这是 AIX 独有的管理工具,非常便捷,功能丰富而且易扩展,几乎所有常用的系统管理任务都可以在 SMIT 中执行。
- Web-based System Management(WebSM),使用基于 Java 的 GUI 界面。使用 WebSM 能管理本地或者远程服务器,完成绝大多数 SMIT 工具支持的任务,并且界面和操作更加接近于现代软件的习惯。WebSM 需要执行一个 Java 的本地程序作为界面,该工具在 AIX 中集成为 WebSM 的一部分,在 Windows 或 Linux 上必须单独下载安装。
在 AIX 6.1 中,新增加了称之为 IBM Systems Director Console 的管理工具。该工具提供了基于 Web 界面的管理手段,因此不需要安装客户端,任何能运行受支持的浏览器的系统都可以连接到该工具执行管理任务。系统管理员通过 IBM Systems Director Console 界面可以访问到:
- 按照 IBM Systems Director Console 方式组织的系统管理任务
- SMIT 菜单的 Web 界面版本
- 系统状态信息
- 其他信息,如 Console 配置等
通 过将系统管理任务集成到 Web 界面,AIX 6.1 提供了更加简便高效的管理手段,对于降低管理难度和成本具有很大的意义。而对于熟练的系统管理员,如不需要使用 IBM Systems Director Console,则可以将其关闭以节省系统资源,只需要将 /etc/inittab 中 pconsole 子系统对应的启动条目删除即可。
2.Workload Manager 增强
工 作负载管理器(Workload Manager)是 AIX 系统内置的资源控制系统,管理员可以使用 WLM 来控制处理器,内存,I/O 资源的分配。在 AIX 6.1 中,WLM 的功能的到增强,用以控制 WPAR 的资源分配。事实上,WPAR 的资源分配控制功能在底层正是由 Workload Manager 提供。但要注意的是,WPAR 的资源控制操作不应该通过 WLM 来直接进行,而应该使用 WPAR 的管理工具,如 WPAR Manager。并且目前 WLM 只支持在全局环境中运行,控制全局环境中的应用或者 WPAR 的资源,而不支持在 WPAR 内运行。
本系列文章旨在带领读者探索 AIX 6.1 中的新特性和对 AIX 5L 中已有功能的增强,并了解这些新特性对用户的影响。在本文的第 1 部分中,我们介绍了 AIX 6.1 在系统基础功能,存储、I/O 和文件系统方面的新功能和增强。在本文的第 2 部分中,向您了网络,性能,虚拟化和可管理性方面的变化。本文为第 3 部分,向您介绍了关于可用性、安全性以及开发方面的一些新的特性和功能。
|
您可以访问“AIX 6 资源中心”了解更多的 AIX 6 的新特性:
|
|
可用性
RAS 组件框架
企业级的 RAS(Reliability,Availability,Serviceability)历来是 IBM System p 服务器和 AIX 操作系统的核心优势,在 AIX 6 中,其 RAS 特性又有了大幅增强,提供了一个组件式的 RAS 基础框架,其中包含以下组件(又称之为 Domain):
- RTEC(Run-Time Error Checking):运行时故障检查,可对系统组件(包括硬件和软件)的故障检测,严重程度级别和处理动作进行定义。AIX 6 中很多设备驱动和子系统都使用了该组件提供的服务,例如 VMM 子系统,存储和磁盘驱动,网络驱动等等。
- CT(Component Tracing):新增的跟踪(Tracing)调试手段。可以用于系统跟踪时提供额外的更加细致的过滤,或者作为单独的跟踪手段来帮助诊断系统问题。
- CD(Component Dump):对 Dump 功能的增强。Dump 信息的详细程度可以进行细化控制,并且可执行 Live Dump(dump 过程不需要停止系统,dump 结束后系统继续运行)。
基于这个框架,AIX 系统自身的各个部分和第三方的软件都可以向系统注册并执行其特有的故障检测和控制,tracing 和 dump 等功能,以提供更加强大和灵活的 RAS 特性。
伴随着 RAS 组件框架还增加了一系列的系统管理命令,其中最主要的是 errctrl,ctctrl 和 dumpctrl 命令,可对各个 AIX 各个子系统或者设备的 RTEC,CT 和 CD 属性进行控制。
Dump 功能的增强
Dump 是 AIX 系统中用于故障诊断的一项非常重要的功能,dump 数据中包括了故障发生时的内存内容和处理器状态等信息,可用于重现故障时的场景以进行分析。旧式的 dump 方法是在崩溃时对整个系统的内存都进行转储,由于现代系统的物理内存越来越大,进行一次完整 dump 的时间也越来越长,间接的增加了由于宕机带来的停机时间。AIX 6 中引入了几种新的 dump 手段,更加灵活方便,对业务影响更小。下表对各种 dump 方式做了总结:
方式 |
AIX 版本 |
说明 |
传统 dump |
所有 |
原始方式,随着 CPU 数量的增加,物理内存的加大,dump 需要的时间也越来越长。 |
Minidump |
V5.3 TL3 |
数据不是像传统的 dump 方式那样保存到磁盘上,而是保存到 NVRAM 中,系统下次启动时,再写入到 error log 中。因此 Minidump 的容量非常小,只保存了关键的信息,同时转储所需要的时间也很短。 |
Parallel dump |
V5.3 TL5 |
Dump 数据存储的格式发生改变,数据块以无序方式存储,使得多处理器的系统可以按照每个处理器同时转储一块区域的方式将内存数据写入到 dump 设备。此改进使得大型系统(多 CPU,大内存)的 dump 速度得到大大提升,仅仅受限于 I/O 速度。 |
Component Dump |
V6 |
在上一主题“RAS 组件框架”中我们已经提到,Component Dump 使得管理员可以对 dump 的详细程度和各组件的 dump 属性进行更加精确的控制。 |
Live Dump |
V6 |
Live Dump 方式基于新的 Component Dump 框架。执行时,只有那些注册到 CD 框架并且声明为支持 Live Dump 特性的组件才会有数据转储。Live Dump 还有另外一项非常重要的特性,就如其名称表明的一样,在 dump 时不需要重新启动系统。因此 Live Dump 方式减少了需要转储的数据并显著的降低了 dump 所需要的停机时间。 |
Firmware-Assisted Dump |
V6 |
传统的 dump 方式实际上是由已经发生故障的 AIX 内核进行的,这样存在两个问题:
- 如何保证由已经故障的内核所写入的数据的正确性
- 故障严重到内核已经无法进行 dump 时,即无法收集任何 dump 信息
在 POWER 6 平台上,系统微码引入了对 AIX dump 的支持。AIX 6 可以在发生崩溃时立即重启,系统微码会保护崩溃时的内存区域的内容不受影响。在 AIX 6 系统启动过程中,内核会将由微码保护起来的内存区域转储并释放。使用此方式,dump 的可靠性得到了大幅提升。 |
可见,在 AIX 6 中,dump 方式的改进主要在于可更加细致的控制 dump 的内容,减少 dump 对系统的影响,增加 dump 过程的可靠性这几方面。
Storage protection keys
Storage protection keys 是 POWER 6 处理器新增加的一项功能,系统内存可以按照区域分配不同的 key,通过硬件提供支持来保证只有持有正确的 key 的代码可以修改其内容。该技术可以应用在 AIX 内核或者用户应用程序代码中,防止由于代码的错误行为(无论是有意还是无意)而可以任意破坏其它内存区域,因此可以进一步提高系统的稳定性。AIX 5.3 TL6 中加入了 Storage protection keys 的 API,应用程序可以使用此功能,但是内核并不支持使用 key 来保护。而 AIX 6 中,内核代码和用户应用代码都可以使用 Storage protection keys 功能。
内核故障恢复
作为系统的关键部分,AIX 内核的稳定性直接影响到整个系统的可用性。如果内核出现了错误,往往造成整个系统直接崩溃。AIX 6 内核包括了自动故障恢复功能(Kernel error recovery),当错误出现时,可以自动采取动作,避免造成崩溃。
AIX 6 内核中增加了一个称之为恢复管理器(Recovery Manager)的组件,所有需要提供故障自动回复的内核组件或者扩展模块都会向 Recovery Manager 注册其特定的恢复例程(Recovery Routine)。当某个组件发生错误时,它会产生一个异常,将执行转交给 Recovery Manager,由其执行该组件的恢复例程。当恢复例程执行结束后,Recovery Manager 会将执行交还该组件,使其继续运行下去。
恢复例程内通常会执行以下操作,使得出错的组件可以恢复到正常的执行状态:
- 收集故障数据
- 检查并恢复数据结构
- 对组件出错时持有的资源进行相应的处理或者释放
- 决定修复为故障而应采取的措施
恢复例程通常在尝试进行任何恢复动作前会先触发一个 Live Dump,并在 AIX error log 中会记录一次内核故障恢复事件(Lable 为 RECOVERY、RECOVERY_NOTIF 或 RECOVERY_TIME)。
内核故障恢复功能的开启可以通过 raso 命令来进行控制,包括受限参数 recovery_action、recovery_average_threshold、recovery_debugger 和 recovery_framework。也可以通过 SMIT 菜单来访问,快捷路径为 krecovery。
在线内核升级(Concurrent update)
在 AIX 6 之前的版本中,任何对 AIX 内核进行更新的操作之后都必须要执行 bosboot 命令更新 Boot LV 然后重新引导系统才会生效,在补丁升级任务结束后经常会看到这样的提示信息,
* * * A T T E N T I O N * * * System boot image has been updated. You should reboot the system as soon as possible to properly integrate the changes and to avoid disruption of current functionality.
|
就是因为这个原因。因此当 IBM 发布一个关键的内核补丁时,用户通常会面临一个两难的局面:如果升级补丁,必须要重新启动,这会带来一段宕机时间;而如果不更新补丁,又会面临潜在的问题。
AIX 6 通过引入在线内核升级(Concurrent update)功能改善了这个问题,该功能的特点在于:
- 安装后不需要重启,即时生效。补丁可以设置为在重启后持续生效,或者仅对本次有效。
- 以临时补丁(Interim Fix)的形式提供,使用 emgr 命令来安装和管理。emgr 命令新增加 -i 参数来安装 concurrent update,具体的信息可以参考 man emgr。
- 如果补丁被安装为应用(Applied)状态,而没有被提交(Commit),那么移除该补丁同样不需要重新启动系统。
- 由于对运行中的内核代码进行动态的修改和替换是一个复杂的过程(AIX 6 的内核专门为此引入了相应的机制和系统调用),因此并不是所有的内核补丁都能够以在线方式升级。对内核的重大改变或者关键部分的升级还是需要计划相应的宕机时间。
换页空间校验
AIX 6 增加了对换页空间(Paging space)数据的正确性校验,通过记录被换页的内存数据的校验和(checksum),AIX 6 确保内存数据在写入到磁盘时和从磁盘读入时是一致的。如果校验数据表明 Paging space 中的数据不正确,AIX 会记录一个错误日志,并根据错误的内存数据属于哪个区域而采取相应的行为:如果属于内核使用的系统内存,那么停机;如果属于应用程序使用的部分,则给相应 的进程发送异常信号。
Paging space 的中的数据以 4KB 为单位计算校验和,校验和长度(checksum size)可以在 8/16/32 bit 中进行选择,如果 checksum size 设置为 0,则关闭了该功能。当打开校验功能时,每个 Paging space 设备会对应一段大小为 256MB 的专用内存区域,用来记录存储到该设备上的每个内存页的校验和。Paging space 的校验和长度设置记录在 /etc/swapspaces 文件中,可以在创建时使用 mkps –c 参数来指定,也可以在创建好之后使用 chps –c 参数来修改。
安全
Trusted AIX
Trusted AIX 是 AIX 6 提供的一种工作模式,在此模式下,AIX 系统使用 Label 对系统中的 Subjects(通常是系统中的进程)和 Objects(被访问的资源,包括文件,内存中的 IPC 对象,网络数据包,以及其他任何资源)进行标记,说明其安全属性。相比于普通的 AIX,在 Trusted AIX 环境下某个 Subject 是否可对某个 Object 执行相应的操作,均需根据其附属的 Label 来进行判断,而通过合理的设置 Label,可以对系统上的数据进行不同级别的保护。
在普通的 AIX 环境下用户可以使用以下一些手段来对数据进行隔离和访问控制:
- 按照 User/Group/Others 角色来分配 Read/Write/Execute 权限,初步控制文件权限
- 用户自主设置的 ACL,文件的属主可以控制 ACL,将访问授权给任何人
- 进程的权限由其有效 UID 和 GID 来决定
- 审计子系统(Audit subsystem)用来审计用户和进程的操作
- 基于角色的访问控制(RBAC)
这些手段也是 UNIX 世界中传统的方式,简单,实用,但是却有着各种不足,例如:
- 文件的属主拥有对文件访问权限的全面控制,一旦设置不当(不论有意或无意),都会有敏感数据泄漏的风险。
- 不论是普通的文件权限位还是 ACL,都只能对“文件”资源进行控制,对诸如内存对象和网络数据包则无能为力。
- 即便是使用了 ACL,文件权限的设定粒度也不够精细。
- 存在一个特殊的用户:root。他可以访问和修改系统内的几乎所有资源,是严重的安全隐患。
Trusted AIX 在这些传统方法的基础之上进一步提供了更加强大和全面的手段,来加强对数据的保护。在 Trusted AIX 环境下可以做到:
- 强制访问控制:文件的属主不能随意修改文件的安全属性,只有被授权的操作员才可以执行这类操作,保证敏感数据的访问受到控制。
- 对进程,文件和其他各种数据设置 Security Label 和 Integrity Label。通过这些 Label 可以精确控制进程对数据的访问和修改权限。
- 细分用户权限,任何用户要访问某个资源或执行某个操作,都必须要有相应的权限。root 不再是一个特殊的万能用户,它与普通用户一样,只能访问有授权的文件。
- 进程和用户执行的操作和其多需的对应权限细分后,系统可以对其进行更加详细的记账和审计操作。
Trusted AIX 设计主要是针对需要极高安全性的用户,例如军事国防等领域。由于控制更加严格,不可避免的增加了管理难度,降低了易用性,并带来一些特定的限制。用户在部署 Trusted AIX 之前需要对此有充分的了解:
- Trusted AIX 模式是否开启由安装时的选项决定,普通模式和 Trusted AIX 模式之间切换只有通过重新覆盖安装来完成。
- 在 Trusted AIX 环境下 root 用户无法登陆系统,这会对一些应用的行为产生影响,例如 NIM 和其他一些需要使用 root 用户通过网络登录执行管理操作的应用程序。
- 由于 root 用户不再可用,新增三个用户 isso,sa 和 so 供系统管理和操作用途。这三个帐户必须在安装结束后第一次启动时设置密码,否则系统无法使用。
- Trusted AIX 环境下创建的 WPAR,也受 Security Label 的控制。
- RBAC 和 Trusted Execution 功能在普通和 Trusted AIX 模式都可用,如果仅仅需要这两个功能,可以不必选择启用 Trusted AIX。
- Trusted AIX 与普通 AIX 兼容,在普通 AIX 模式下能正常工作的应用程序在 Trusted AIX 下也可以正常运行。但由于 Trusted AIX 下应用程序的操作都受到更多的限制,因此程序很可能会由于安全规则设置的原因无法正常工作。管理员可以使用 tracepriv 命令来帮助诊断此类问题。
Trusted Execution Environment
在 AIX 5L 中有一项称之为 Trusted Computing Base(TCB)的安全特性,该功能主要用于保证关键的系统文件是可信的。TCB 通过 crontab 定时对关键的系统文件属性进行扫描,并将结果与其保存在数据库内的数据进行对比,以鉴别这些文件是否被修改过。TCB 可以在一定程度上保证系统不受被篡改过的程序的危害。AIX 6 中开始提供了一个新的功能,称之为 Trusted Execution(TE) Environment,可以看作为 Trusted Computing Base 的增强。原有的 TCB 仍然可用,用户可以在这两者间选择启用任意一个。
TE 与 TCB 最大的不同在于,TCB 只能依赖于 crontab 这类方法来定时检查关键文件的正确性,两次检查之间会存在一个窗口期;而 TE 除此之外,还可以在文件 每次 被访问(执行)的时刻,即时进行检查,以确保任何时候载入的代码都是可信任的。TE 维护一个称之为 Trusted Signature Database(TSD)的数据库,其中记录了受到保护的文件的各类属性,最重要的是文件哈希值(Hash),通过对比 TSD 中和磁盘上的文件的 Hash 值,即可以判断文件是否处于完整可信,未被篡改的状态。
Trusted Execution 提供了 trustchk 命令来设置 TE 的工作策略,对系统的进行完整性检查和管理 TSD。正如前文曾经提到过的,完整性检查有两种工作方式:
系统完整性检查 在每次系统启动时,或者在 crontab 中定时运行,对整个系统中受到监控的文件的属性进行扫描,与 TSD 中存储的信息进行对比。
运行时完整性检查 在收到保护的文件每次被读入时对其签名进行检查,确保文件始终是可信的,而不是被篡改过(例如插入了木马,恶意代码)。
Trusted Execution 策略可以设置为对执行文件,共享库,脚本和内核扩展模块进行检查;可以锁定 TSD 数据库和受保护的文件为不可修改状态;还可以设置受信任的执行文件和共享库路径,只有在此路径下的执行文件和共享库才能被调用。将这些策略进行适当的设置 和组合,可以对系统关键文件的完整性进行灵活而强大的保护。
Trusted Execution 与 Trusted Computing Base 另外一个不同在于,TCB 是安装时的选项,其开启和关闭必须在安装时就进行选择,而 TE 是一个动态选项,可以通过 trustchk 命令来动态控制开启或者关闭。
增强的基于角色的访问控制(Role Based Access Control)
增强的 Role Based Access Control(RBAC)是 AIX 6 中另一项非常重要的安全特性,事实上,从 AIX 4.2 开始便包含了一个 RBAC 应用框架,但该框架有如下不足:
- 应用程序需要做相应的修改才能利用该框架支持 RBAC。
- 预定义的授权体系粒度不够。
- 为执行某些程序,用户经常需要具有某个特定的组身份(group membership)和角色(role)。
- 在用户角色(role)的管理上不够强大和灵活。
- 尚未达到“最小权限”原则的要求,许多特权命令依然还是需要被设置为 SUID。
为了解决这些问题,AIX 6 中引入的了一个新的 RBAC 框架,称之为 Enhanced RBAC,原有的框架改称为 Legacy RBAC。
RBAC 的核心思想是将权限细分,并与用户分离,用户在执行某个特权操作时,只需要具有相应的最小权限,而不需要拥有某个特殊的用户身份和其他不相干的权限。RBAC 框架中有以下几个重要的概念:
授权(Authorizations)授权是对用户的能力的定义。在执行任务时,用户必须要具有对应的授权才能够使用特定的命令。
特权(Privileges)特权是对进程的能力的定义。进程需要有足够的特权级才能进行受到安全限制的操作。
角色(Roles)角色是将授权赋予给某个用户的手段。一个角色可以包含有为执行某个任务而需要的多个授权,当该角色被赋予某个用户时,该用户即拥有了这些授权,可以执行对应的系统管理任务。
如果没有 RBAC,系统的权限实际上集中在特定的用户手上,无法分离。典型的是 root 用户,可以访问系统中所有资源,以 root 身份运行的程序也就可以执行任意的操作。如果普通的用户需要执行某个操作,比如管理文件系统,由于权限与用户身份绑定在一起,那么他只能设法以 root 身份来执行任务,例如使用 SUID 的程序。引入 RBAC 支持之后,权限和用户不再是绑定的。用户如果需要某个特权来执行管理操作,他只需要获得相应的授权即可,不需要改变自己的身份。
默认情况下 RBAC 的配置文件位于 /etc/security 目录下,保存了角色,授权,特权命令,特权设备和特权文件数据。对这些配置修改后,管理员需要使用 setkst 命令将配置文件中的数据上传到 AIX 内核中的 Kernel Security Table(KST)才会生效。配置文件数据还可以存放在 LDAP 目录中,该特性由 /etc/nscontrol.conf 文件控制。通过将 RBAC 配置保存在 LDAP 目录中,多个 AIX 服务器可以共享同样的 RBAC 配置,简化企业网络的安全管理。
超过 8 字符的密码支持
AIX 5L 中支持的最大密码长度为 8 个字符长,这是由于密码加密过程算法使用的是 crypt() 调用,该方法会将密码在 8 字节处截断。从 AIX 6.1 和 AIX 5.3 TL7 开始,支持可加载的密码算法(Loadable Password Algorithm),这样 AIX 系统可以支持更多种密码算法来对密码进行加密,并且密码的最大长度也扩展到了 255 个字符(各种密码加密算法支持的最大长度不同)。由于密码算法可变,密码长度更长,用户密码被暴力破解的可能性也就相应降低了。
内核和应用开发环境
ProbeVue
AIX 6 中引入了称之为 ProbeVue 的新的的跟踪手段,它的最大特点在动态跟踪。“动态”意味着应用程序不需要做任何修改就可以在运行过程中随时插入跟踪点,收集执行时的状态数据。而以往的 跟踪方法(静态跟踪)需要在程序源代码中加入跟踪点,并在编译时使用对应的选项以生成带跟踪和调试信息的执行文件。由于加入这些额外信息的程序往往执行速 度更慢并占用更多内存,因此生产系统通常不会运行运行这些调试版本的代码,导致发生程序发生问题时,往往需要停止原来的生产版本程序,启动带跟踪信息的版 本,等待问题再次发生然后进行跟踪调试。相比之下使用 ProbeVue 可以在生产系统中不用中断应用程序,随时可以被跟踪收集信息。
ProbeVue 中重要的概念包括:
Probe 中断正在执行的代码,以收集当时系统状态和进程上下文信息的动作。
Probe Action 在一个 Probe 中执行的具体动作,通常包括收集各种系统全局数据和进程特有的上下文信息的过程,并将这些信息保存到缓冲区,供跟踪工具读取和分析。
Probe Point 程序代码执行过程中可以进行 Probe 操作的位置。ProbeVue 支持两种类型的 Probe Point:Probe Location 和 Probe Event
Probe Location 代码中的某个具体的位置,当执行到这个位置时,该点的 Probe Action 就会被触发
Probe Event 对应于一个抽象的事件(Event)而不是具体的代码位置,当某个 Event 发生时,触发具体的 Probe Action。
ProbeVue 使用称之为 Vue 的专用脚本语言来进行具体的跟踪工作, Vue 脚本的主要内容可以归纳为
- 一个或多个 Probe 语句:在某个 Probe Point,如果满足某个条件断言(Predicate),则执行某个 Probe Action 代码段。简单来讲,就是何时,何处执行什么跟踪操作。
- 可选的初始化操作和退出时的清理操作。
Vue 脚本通过将多个 Probe 语句组合到一起可以完成非常复杂的跟踪操作,收集丰富的调试信息,大大的增强了 AIX 系统下的调试手段。
TI-RPC
传输无关的 RPC(Transport Independent Remote Procedure Call)是 AIX 内包含的一套应用编程接口(API),它使得在编写使用 RPC 方式进行网络计算的应用程序时不再需要关注下层具体的传输协议(常见的如 TCP,UDP,或者其他任何支持的网络传输协议)。应用程序只需要关注具体的 RPC 问题,而 TI-RPC 会处理下层的传输细节,这样可以大大增加应用程序的可移植性。
在 AIX 6 之前,AIX 系统内部已经提供了 TI-RPC 接口,主要供操作系统自身使用(例如 NFS 功能),但是 IBM 并不为客户使用该 API 提供支持。从 AIX 6 开始,IBM 正式支持 TI-RPC 作为 AIX 标准的编程接口。同时该接口也保持与 Sun Solaris 系统中的 TI-RPC API 的兼容性,应用程序移植时几乎不需要做任何修改。
总结
到此为止,我们对 AIX 6 中的新增功能和对原有特性的增强做了一个比较全面的介绍,由于篇幅的关系,很多细节没有进行详细的描述,并且还有不少特性由于涉及内容太过于深入也没有介 绍到。读者可以参考 IBM 红皮书《IBM AIX Version 6.1 Differences Guide》来学习更多具体的内容。