深入Linux?PAM?体系结构

    本文阐述了 Linux-PAM 的概念，同时还与读者一道分析了 Linux-PAM 的体系结构，作者希望籍此以加深读者对 Linux-PAM 的理解，以便对其有更深层的把握。

一、什么是Linux-PAM

    为安全起见，计算机系统只有经过授权的合法用户才能访问，在这里如何正确鉴别用户的真实身份是一个关键的问题。所谓用户鉴别，就是用户向系统以一种安全的方式提交自己的身份证明，然后由系统确认用户的身份是否属实的过程。换句话说，用户鉴别是系统的门户，每个用户进入到系统中都必须经过鉴别这一道关。 

    最初，Linux系统的用户鉴别过程就像各种Unix系统的一样：系统管理员为用户建立一个帐号并为其指定一个口令，用户用此指定的口令登录后重新设置自己的口令，这样用户就具有了一个只有他自己知道的秘密口令。一般情况下，用户的口令经过加密处理后存放于 /etc/passwd 文件中。用户登录时，登录服务程序提示用户输入其用户名和口令，然后将口令加密并与 /etc/passwd 文件中对应帐号的加密口令进行比较，如果口令相匹配，说明用户的身份属实并允许此用户访问系统。这种思想基于只有用户自己知道他的口令，所以输入的口令是正确的话，那么系统就认定他是所声称的那个人。 

    后来，还采用了许多其他的鉴别用户的方法，如用于网络环境的 Kerberos 以及基于智能卡的鉴别系统等。但是这些鉴别方案有一个通病：实现鉴别功能的代码通常作为应用程序的一部分而一起编译,这样问题就来了------如果发现所用算法存在某些缺陷或想采用另一种鉴别方法时，用户不得不重写（修改或替换）然后重新编译原程序。很明显，我们原先的鉴别方案缺乏灵活性，这里的牵一发而动全身的情形很是让人恼火。 

    鉴于以上原因，人们开始寻找一种更佳的替代方案：一方面，将鉴别功能从应用中独立出来，单独进行模块化设计，实现和维护；另一方面，为这些鉴别模块建立标准 API，以便各应用程序能方便的使用它们提供的各种功能；同时，鉴别机制对其上层用户（包括应用程序和最终用户）是透明的。直到 1995 年，SUN 的研究人员提出了一种满足以上需求的方案--插件式鉴别模块（PAM）机制并首次在其操作系统 Solaris 2.3 上部分实现。插件式鉴别模块（PAM）机制采用模块化设计和插件功能，使得我们可以轻易地在应用程序中插入新的鉴别模块或替换原先的组件,而不必对应用程序做任何修改，从而使软件的定制、维持和升级更加轻松--因为鉴别机制与应用程序之间相对独立。应用程序可以通过 PAM API 方便的使用 PAM 提供的各种鉴别功能，而不必了解太多的底层细节。此外，PAM的易用性也较强，主要表现在它对上层屏蔽了鉴别的具体细节，所以用户不必被迫学习各种各样的鉴别方式，也不必记住多个口令；又由于它实现了多鉴别机制的集成问题，所以单个程序可以轻易集成多种鉴别机制如 Kerberos 鉴别机制和 Diffie - Hellman 鉴别机制等，但用户仍可以用同一个口令登录而感觉不到采取了各种不同鉴别方法。 

    在广大开发人员的努力下，各版本的 UNIX 系统陆续提供对 PAM 的支持。其中，Linux-PAM 是专门为 Linux 机器实现的，包括 Caldera 1.3、2.2、Debian 2.2、Turbo Linux 3.6、Red Hat 5.0 以及 SuSE 6.2 及它们的后续版本都提供对 PAM 的支持。FreeBSD 从 3.1 版开始支持 PAM。需要注意的是，除了具体实现不同外，各种版本 Unix 系统上的 PAM 的框架是相同的，所以我们在这里介绍的 Linux-PAM 框架知识具有普遍性。因此在下文介绍其框架的过程中可以看到，我们并没有刻意区分 PAM 与 Linux－PAM 这两个术语。 

二、PAM 的分层体系结构

    PAM 为了实现其插件功能和易用性，它采取了分层设计思想：让各鉴别模块从应用程序中独立出来，然后通过PAM API作为两者联系的纽带，这样应用程序就可以根据需要灵活地在其中"插入"所需鉴别功能模块，从而真正实现了"鉴别功能，随需应变"。实际上，这一思路非常符合软件设计中的"高内聚，低耦合"这一重要思想，PAM 的体系如下简图所示： 

图1 PAM体系结构 

    从上图可以看出，PAM API 起着承上启下的作用，它是应用程序和鉴别模块之间联系的纽带：当应用程序调用 PAM API 时,应用接口层按照配置文件 pam.conf 的规定，加载相应的鉴别模块。然后把请求（即从应用程序那里得到的参数）传递给底层的鉴别模块,这时鉴别模块就可以根据要求执行具体的鉴别操作了。当鉴别模块执行完相应操作后，将结果返回给应用接口层，然后由接口层根据配置的具体情况将来自鉴别模块的应答返回给应用程序。 

    上面描述了 PAM 的各个组成部分，以及它们作为整体的运作机理。下面将对 PAM 的关键的低二层分别加以介绍。 

三、第一层：模块层

    模块层处于整个结构的最底层，它向上为接口层提供用户鉴别等服务，也就是说所有具体的鉴别工作都是由该层的模块来完成的。对于应用程序，有些不但需要验证用户的口令，还可能要求验证用户的帐户是否已经过期。此外,有些应用程序也许还会要求记录当前会话的有关信息或改变口令等，所以 PAM 在模块层除了提供鉴别模块外，同时提供了支持帐户管理、会话管理以及口令管理功能的模块。当然,这四种模块并不是所有应用程序所必需的,而是根据需要灵活取舍,比如虽然 login 可能要求访问所有四种模块,但是 su 可能仅仅需要使用鉴别组件即可。至于如何取舍则涉及到接口层的 PAM API和配置文件,这部分内容将在下文中加以介绍。 

四、第二层：应用接口层

    应用接口层位于 PAM 结构的中间部分，它向上为应用程序屏蔽了用户鉴别等过程的具体细节，向下调用模块层中的具体模块所提供的特定服务。由图1可以看出，它主要由 PAM API 和配置文件两部分组成，下面将逐一介绍。 

PAM API 可以分为两类，一类是用于调用下层特定模块的接口，这类接口与底层的模块相对应： 

1. 鉴别类接口：pam_authenticate（）用于鉴别用户，pam_setcred（）用于修改用户的秘密信息。 

2. 帐号类接口：pam_acct_mgmt（）检查受鉴别的用户所持帐户是否有权登陆系统，以及该帐户是否已过期等。 

3. 会话类接口：包括用于会话管理和记帐的 pam_open_session（）和 pam_close_session（）函数。 

4. 口令类接口：包括用于修改用户口令的 pam_chauthtok（）。 

    第二类接口通常并不与底层模块一一对应，它们的作用是对底层模块提供支持以及实现应用程序与模块之间的通信等。具体如下： 

1. 管理性接口 
每组 PAM 事务从 pam_start（）开始，结束于 pam_end（）函数。接口 pam_get_item（）和 pam_set_item（）用来读写与 PAM 事务有关的状态信息。同时，能够用 pam_str()输出 PAM 接口的出错信息。 

2. 应用程序与模块间的通讯接口 
在应用程序初始化期间,某些诸如用户名之类的数据可以通过 pam_start（）将其存放在PAM接口层中，以备将来底层模块使用。另外，底层模块还可以使用 pam_putenv()向应用程序传递特定的环境变量，然后应用程序利用 pam_getenv() 和 pam_getenvlist() 读取这些变量。 

3. 用户与模块间的通讯接口 
pam_start（）函数可以通过会话式的回调函数，让底层模块通过它们读写模块相关的鉴别信息，比如以应用程序所规定的方式提示用户输入口令。 

4. 模块间通讯接口 
尽管各模块是独立的,但是他们仍然能够通过 pam_get_item（）和 pam_set_item（）接口共享某些与鉴别会话有关的公用信息，诸如用户名、服务名、口令等。此外，这些API还可以用于在调用 pam_start（）之后，让应用程序修改状态信息。 

5. 读写模块状态信息的接口 
接口 pam_get_data（）和 pam_set_data（）用以按照PAM句柄要求访问和更新特定模块的信息。此外，还可以在这些模块后附加一个清除数据函数，以便当调用 pam_end（）时清除现场。 

    由于 PAM 模块随需加载,所以各模块始化任务在第一次调用时完成。如果某些模块的清除任务必须在鉴别会话结束时完成,则它们应该使用 pam_set_data（）规定清除函数，这些执行清除任务的函数将在应用程序调用 pam_end（）接口时被调用。 

五、配置文件

    我们注意到，配置文件也放在了在应用接口层中，它与 PAM API 配合使用，从而达到了在应用中灵活插入所需鉴别模块的目的。它的作用主要是为应用选定具体的鉴别模块，模块间的组合以及规定模块的行为。下面是一个示例配置文件： 

图2.示例配置文件 

    我们可以看到,配置文件有许多登记项(每行对应一个登记项)组成,每一行又分为五列(每列对应一栏),详细解释如下: 

    第一栏，service表示使用PAM的应用程序，比如login、passwd、rlogin等。这一栏中的 OTHER表示所有没在该文件中显式列出的应用。也就是说，如果所有程序具有相同的需求，整个配置文件只需要一行即可，并且该行的第一栏为OTHER。本例中，因为所有应用程序使用相同的会话模块,所以实际上可以用单行，即 

" OTHER   auth        required     pam_unix_auth.so"

来代替文件中的这些行： 

"login   session     required     pam_unix_session.so

ftp     session     required     pam_unix_session.so

telnet  session     required     pam_unix_session.so"。

第二栏,module_type 指明程序所用PAM底层模块的类型：auth表示鉴别类模块；account表示帐户类模块；session表示会话类模块；password表示口令类模块。注意，每行只能指定一种类型模块，如果程序需要多种模块的话，可在多行中分别规定。 

    第三栏,control_flag规定如何处理模块的成功和失败情况。单个应用程序可以调用多种底层模块，这通常称为"堆叠"，对应于某程序的按照配置文件中出现顺序执行的所有模块成为"堆"，堆中的各模块的地位与出错时的处理由control_flag栏的取值决定，它的五种可能的取值分别为required、Requisite、sufficient或_optional，现介绍如下： 

    required--它表示该模块的成功是用户通过鉴别的必要条件，换句话说，只有当对应于应用程序的所有带 required标记的模块全部成功后，该程序才能通过鉴别。同时，如果任何带required标记的模块出现了错误，PAM并不立刻将错误消息返回给应用程序，而是在所有模块都调用完毕后才将错误消息返回调用它的程序。 

    Requisite--它与required相仿，只有带此标记的模块返回成功后，用户才能通过鉴别，不同之处在于其一旦失败就不再执行堆中后面的其它模块，并且鉴别过程到此结束。 

    optional--它表示即便该模块失败，用户仍能通过鉴别。在PAM体系中，带有该标记的模块失败后将继续处理下一模块。 

    sufficient--它表示该模块取得成功是用户通过鉴别的充分条件,也就是说只要标记为sufficient的模块一旦成功，那么PAM便立即向应用程序返回成功而不必尝试任何其他模块。当标记为sufficient的模块失败时，sufficient模块当做 optional对待。 

    第四栏,module_path指出PAM模块的位置。 

    第五栏,options用于向特定模块传递相关的选项，然后由模块分析解释这些任选项。比如使用此栏打开模块调试，或向某模块传递诸如超时值之类的参数等。另外，它还用于支持下文所述的口令映射技术。 

    如果任一栏出现错误,或某模块没有找到,那么所在行被忽略并将其作为严重错误进行记录。 

    本例中，login程序使用UNIX口令模块进行鉴别，而ftp程序却使用S/Key模块进行鉴别。如我们想改变ftp程序的鉴别方法，比如也用UNIX口令模块进行鉴别，那么我们不必改动源程序，只需将配置文件中的 

ftp     auth        required     pam_skey_auth.so    debug

改为

ftp     auth        required     pam_unix_auth.so    debug

    这样，当用户使用ftp时，将用传统的UNIX口令鉴别方式来验证其身份。由此可见，在PAM体制下为应用程序改变鉴别机制是一件轻松的事情。另外，PAM体制的堆叠功能还使得应用程序能够支持多种鉴别机制，如下例中的login程序在配置文件中先后出现了三项与鉴别有关的登记项： 

图3.示例配置文件 

    当login 程序执行时先用pam_unix.so模块即传统的UNIX口令方式鉴别用户，然后再调用pam_kerb.so模块即Kerberos对用户进行鉴别，最后用pam_rsa.so模块即RSA方式鉴别用户。在按上述顺序鉴别用户的过程中，如果pam_unix.so模块鉴别失败，它将继续调用下面的模块进行鉴别而非立刻向login程序返回错误消息；pam_kerb.so模块也按同样方式处理，直到顺序处理完最后一个pam_rsa.so模块后， PAM才将前面出现的错误信息返回给login程序。对于该配置，即使pam_rsa.so模块顺利通过，只要pam_unix.so模块和 pam_kerb.so模块中有一个出现错误，用户就不能通过鉴别；相反，即使pam_rsa.so模块失败，只要pam_unix.so模块和 pam_kerb.so模块都通过了，用户也能通过鉴别。