可插拔认证模块

定义

可插拔认证模块是一种把多种底层认证方案集成到高层应用编程接口的机制，其目标在于让需要身份验证的程序不再与具体的认证实现绑定。Linux-PAM 是一套处理系统上应用程序认证任务的库，向需要授予权限的程序提供稳定的通用接口，使登录、切换用户等程序可以把认证工作交给它完成^[3]。

在 Linux 上，PAM 把认证相关任务划分为账户管理、认证管理、密码管理和会话管理 4 个相互独立的管理组，配置文件中使用 account、auth、password、session 这 4 个缩写来指代^[3]。其中认证组负责核实用户身份并建立用户凭据，账户组负责检查账号是否仍然有效，密码组负责更新认证凭据，会话组则在服务开始之前和结束之后处理审计记录、挂载用户主目录等事务^[3]。

认证方式本身具有动态可配置的特点，管理员可以自行决定各个提供服务的应用程序用什么方式验证用户^[3]。除了传统的口令输入，使用合适的模块也可以接入智能卡、生物识别设备等硬件认证方案^[3]。

原理

PAM 的架构由 4 个部分组成：使用 PAM 的应用程序、PAM 库、PAM 配置以及被称为提供者的 PAM 服务模块^[1]。应用程序通过 PAM 应用编程接口与 PAM 库通信，模块则通过 PAM 服务提供者接口与 PAM 库通信，库本身在应用程序与模块之间充当中间层^[1]。这样应用程序开发者不必了解认证策略的具体语义，认证算法集中提供，并可以脱离各个应用程序单独修改^[1]。

配置由文本文件定义。系统可以只使用单一配置文件 /etc/pam.conf，也可以为每个服务提供独立的配置文件并集中放在 /etc/pam.d/ 目录下；只要该目录存在，Linux-PAM 就会忽略 /etc/pam.conf^[3]。配置行的字段依次为服务名、模块类型、控制标志、模块路径以及传给模块的选项。模块文件通常放在 /lib/security 或 /lib64/security 目录中，模块路径在模块位于默认目录时可以省略^[4]。

多个模块按配置顺序组成一条模块栈依次执行，每个模块的返回结果依据其控制标志被整合处理。常用控制标志包括：required 要求该模块必须成功，失败结果会等到栈中其余同标志模块执行完毕才返回；requisite 在失败时立即终止后续处理；sufficient 在成功且此前无失败时立即结束整个栈；optional 的结果不影响整体判断^[4]。Solaris 等系统还引入了 binding 与 definitive 等扩展标志。

以 su 命令为例，程序先调用 pam_start() 启动会话，PAM 加载 /etc/pam.d/su 中的配置，随后按顺序执行 pam_rootok.so、pam_wheel.so、pam_unix.so 等模块，各模块结果汇总后返回最终认证结论^[5]。整个栈只有在至少调用过一个模块、且所有非 optional 模块均成功时才会放行请求^[6]。

发展历程

PAM 最初由太阳微系统在 1995 年 10 月的开放软件基金会征求意见稿 RFC 86.0 中提出，并被通用桌面环境采用为其身份验证框架。该机制由太阳微系统的 Vipin Samar 和 Charlie Lai 设计，用于解决传统 UNIX 认证机制灵活性不足的问题，以支持更强的安全性和更多样的验证手段。

作为独立的基础设施，PAM 以开源项目 Linux-PAM 的形式于 1996 年 8 月首次出现在 Red Hat Linux 3.0.4 中。在 Solaris 系统中，从 Solaris 2.6 版本开始提供可插拔鉴别模块支持，此后 Solaris 8 引入 pam_ldap 模块以便直接向目录服务器认证，Solaris 9 引入多个取代 pam_unix 的模块，Solaris 10 增加了严格口令检查、帐户锁定和 binding 控制标志等功能。

由于并不存在规范 PAM 行为的中心标准，后来在 X/Open 的 UNIX 标准化过程中出现了 X/Open 单点登录(XSSO)标准。该标准未获批准，但其草案成为后续若干 PAM 实现(如 OpenPAM)的参考资料。Open Group 于 1997 年公布了最初的 XSSO 规范，对 PAM 接口进行标准化并加入单点登录方面的扩展^[6]。

目前支持 PAM 的操作系统包括 AIX、DragonFly BSD、FreeBSD、HP-UX、Linux、macOS、NetBSD 和 Solaris。由于 XSSO 标准与最初的 RFC 以及 Linux、Sun 的接口都不相同，各实现的行为并不一致，OpenBSD 因此选择了源自 BSD/OS 的 BSD 认证框架。

应用

PAM 广泛用于各类需要身份验证的系统服务，典型场景包括用户登录认证(如 SSH、控制台登录)、特权操作授权(如 sudo)、服务访问控制(如 FTP、数据库)以及密码策略管理^[7]。在红帽企业 Linux 中，大多数系统应用程序都依赖底层 PAM 配置进行身份验证和授权^[2]。

PAM 的可插拔性来自面向不同认证来源的模块，例如针对 Kerberos、SSSD、NIS 或本地文件系统的模块，管理员可以让系统优先使用其中某一种认证来源^[2]。常用的模块包括进行传统 UNIX 口令认证的 pam_unix.so、对接目录服务的 pam_ldap.so、做密码强度检查的 pam_pwquality.so，以及限制登录失败次数的 pam_tally2.so 等^[7]。

新的模块可以随时编写并供支持 PAM 的程序使用，此类程序能够立即使用新模块及其定义的方法，无需重新编译或修改^[2]。组合多个模块还可以在同一个服务上叠加多种认证手段，例如同时要求口令与一次性验证码^[8]。

PAM 也为终端用户带来便利，例如不同认证服务的口令相同时无需重复输入，用户也不必为了向多个认证服务提供口令而执行多条命令^[1]。站点级的安全策略可以通过 PAM 配置实现，而不必改动系统入口服务^[1]。

局限

大多数 PAM 实现本身并不与远程客户端交互，因此 PAM 单独无法实现 Kerberos，而后者是 UNIX 环境中最常见的单点登录类型。这一功能缺失促使单点登录被纳入 XSSO 标准的"主要认证"部分，也推动了 SPNEGO、SASL 等技术的出现，并且是 SSH 自行实现认证机制协商的原因之一。

在多数 PAM 实现中，pam_krb5 只能获取票据授权票据，这需要提示用户输入凭据，并且仅用于单点登录环境中的初始登录。若要在不再提示用户输入凭据的前提下取得某个应用程序的服务票证，该应用程序必须专门编码以支持 Kerberos，因为 pam_krb5 自身无法获取服务票证。

PAM 会话在本质上是局限于单台机器的^[9]。在负载均衡配置下，会话可能启动在多个节点上；配合 Kubernetes 使用作业启动器时，会话也可能同时出现在服务器节点和运行会话的容器之中；在 Slurm 环境中，会话则可能运行于提交节点和计算节点^[9]。

PAM 系统的模块本身假设被认证的用户知道自己的身份和对应口令，并且假定用于与用户通信的端口已经建立、用户与显示设备是静态配置好的，其配置并不会在请求到来时动态进行^[10]。

参见

• Kerberos —— 一种网络认证协议，PAM 可通过相应模块与其集成。

• 单点登录 —— 一次认证即可访问多个系统的机制，与 PAM 的模块化认证相关。

• OpenPAM —— 一个 PAM 实现，参考了 XSSO 标准的草案。

• 名称服务开关 —— 与 PAM 同为系统层可插拔框架，负责名字与服务的解析切换。

• 身份管理 —— 涵盖认证、授权与账号治理的更大范畴。