Linux-PAM简介

注： PAM的implementation在不同的＊Nix系统上稍有不同，这里我以RedHat Enterprise Linux 4为蓝本。如果你系统的PAM配置有不同，请安实际情况配置。

Linux-PAM（Pluggable Authentication Modules). 有人翻译成“可插拔式认证模块”, 或是“可插入式认证模块”. 它表示一种性能健硕而且灵活方便的用户级认证方式。目前，PAM已经成为了Linux, BSD和其他一些＊Nix操作系统的首选认证方式。特别是在Linux上，几乎所有的daemon和一些与授权有关的命令都通过PAM来进行验证。他们在编译时都无一例外的加入了对PAM的支持。PAM可以说是Linux系统的安全守护神。那么，PAM到底是怎样运作的呢？

 

PAM主要是由一组共享库文件（share libraries,也就是.so文件）和一些配置文件组成的。当你在请求服务的时候，具有PAM认证功能的应用程序将与这些.so文件进行交互，以便得知是否可以授权给发起请求的用户来使用服务，比如su, vsftp, httpd,等。如果认证成功了，那么这个用户便可以使用服务或完成命令，如果认证失败了，那么这个用户将不能使用服务，同时，PAM将向指定的log文件写入警告信息。我们可以将PAM看作是一个中间裁判，它不依赖于任何应用或服务。你完全可以升级这些应用或服务而不必管PAM的共享库的更新或升级，反之亦然。所以它非常的灵活。

 

PAM的认证过程是通过对一些服务或应用的配置文件来控制的。通常，这些配置文件在/etc/pam.d目录下。cd到这个目录，你会看到很多你很熟悉的应用或服务的名称。比如说login. 那么当用户login的时候，PAM到底做了什么呢？我们看看这个login的PAM配置文件：

Shell代码

#%PAM-1.0 

auth       required     pam_stack.so service=system-auth 

auth       required     pam_nologin.so 

account    required     pam_stack.so service=system-auth 

password   required     pam_stack.so service=system-auth 

# pam_selinux.so close should be the first session rule 

#session    required    pam_selinux.so close 

session    required     pam_stack.so service=system-auth 

session    optional     pam_console.so 

# pam_selinux.so open should be the last session rule 

#session    required    pam_selinux.so multiple open 

这里有些PAM的术语：

首先是配置文件的格式：

Shell代码

service module-type control_flag   module_path args 

service - 由于现代的PAM配置文件都是以服务程序的名字分开配置，所以基本上service这个项已经省去了。但在有些还使用一个pam.conf大文件配置所有的PAM服务的BSD上，还有这一项。

 

module_type – 控制使用什么类型的管理机制。

auth – 认证管理。做两件事：1.检验用户是否是真正声称的那个用户,比如，要求用户输入用户名和密码来声明自己。2.这个模块可以通过PAM自身的印证机制赋予用户一些特权，或是加入组。

account – 用户管理。 是非认证式的对用户赋予／阻止使用一些系统资源。比如说，用户登录的时间限制，密码的期限等。

password – 密码认证管理。是用来管理用户的密码认证标记(token)的。比如，用户密码的尝试次数等。

session – 会话管理。比如在会话前中后所要执行的一些事情，如记录会话信息,对如可展开会话的控制等。

 

control_flag – 可以理解成对PAM认证的流程控制。比如说如果成功，下一步应该怎么办？如果不成功，又应该怎么办？还有就是按怎样的顺序来进行认证，等等。

required – 表示这一模块的认证是必须成功的，但如果失败，认证过程不会即刻终止，PAM将继续下一个同类型的模块认证。

requisite – 和required类似，只是如果失败，认证过程将立即终止。

sufficient – 表示如果认证成功，那么对这一类的模块认证是充足的了，其他的模块将不会再检验。

optional – 表示这一模块认证是可选的，也不会对认证成功或失败产生影响。我没怎么用过这个。

include － 有点类似于DNS或xinetd的include。表示将包括其他的一些认证，这样就可以建立一个分离式的配置文件管理机制。

 

module_path

使用的认证模块的位置，最为保险的是使用绝对路径。不过PAM有自己的PATH环境，在RHEL4中，大部分是使用的相对路径。如果你是缺省安装，有没有挪动过那些.so文件的位置，使用相对路径是没问题的。(缺省路径一般是：/lib/security)

 

args – 在认证时传给模块的一些变量。比如用什么文件，对于什么uid, 失败的处理等等。类似于赋给一个命令一些参数。

 

好了，对于PAM的结构有了基本的了解，我们来看看PAM是如果控制login的。从上至下对于login的PAM配置文件的翻译可以为：

1.用pam_stack.so这个认证模块检测system-auth服务的每一项，看这个请求用户是否能通过认证。这一项是必须检验成功的。system-auth可以理解为一个“systemwide“全局性的PAM配置文件，也就是说所有的PAM文件都将首先检测system-auth。这就是通过pam_stack.soservice=system-auth这一语句来完成的。

2.如果第一项失败了，则整个认证将失败，但无论认证是否成功失败，继续检测第二项，pam_nologin.so.看看系统是否有nologin文件存在。一般在/etc/nologin.如果这个文件存在，则只有root才能登录，其他任何用户都不能。

3.继续检测第三项,用system-auth来检测对用户的管理。

4.继续检测第四项，用system-auth来检测对密码的管理。

5.继续检测第五项，用system-auth来检测会话的控制。

6.继续检测第六项，用pam_console.so来检测用户的登录来源，如果从console,则配置一些console下的资源。这一项是可选的。

 

按照这个认证过程，我们可以举个例子： userA 和userB。UserA是系统用户而userB是个虚拟用户，只给vsftp用的。那么当userA和userB登录的时候，PAM将利用pam_unix.so来检测用户是否在/etc/passwd和/etc/shadow中。显然userA将成功，而userB将失败。成功的用乎将继续检测其诸如password已经retry的次数，是否sync了passwd和shadow文件，是否是nis 用户，password的加密方式，登录后的系统资源利用情况(pam_limits.so)等等。最后是pam_console.so，如果用户是从vt或本地的X 会话登录，PAM将如何配置文件权限...

 

几个常用的PAM认证模块的介绍

1.pam_access.so – 缺省配置文件是/etc/security/access.conf（当然，通过“accessfile=/path/to/file” argument, 还可以自行指定配置文件。 通过加入这个认证模块到你想要控制的服务器PAM配置文件，你可以实现对某些服务的userbase级控制。如vsftp, samba,等。编辑/etc/security/access.conf文件，加入你想要控制的用户，可以赋予／阻止他们从特定的来源登录服务器。

2.pam_cracklib.so – 用字典方式检测password的安全性。有一些很有用的arguments, 比如准许retry的次数，多少个字符可以和上次的密码重复，最小的密码长度等等。

3.pam_deny.so – 一个特殊的PAM模块，这个模块将永远返回否。类似大多数的安全机制配置准则，一个严谨的安全规则的最后一项永远是否。

4.pam_limits.so – 类似Linux的ulimit命令，赋给用户登录某个会话的资源限度。如core文件的大小，memory的用量，process的用量，等等。

5.pam_listfile.so – 高度自定义的一个认证模块。理论上你可以用这个模块来控制任何服务。Arguments有：

Shell代码

item=[tty|user|rhost|ruser|group|shell] 

sense=[allow|deny] 

file=/path/to/the/file 

apply=[usre|@group] 

 

比如，我想在pop3服务的PAM配置文件中加入：

Shell代码

auth       required     pam_listfile.so item=user sense=denyfile=/etc/security/dovecot.deny onerr=fail 

 

然后我建立/etc/security/dovecot.deny文件，在里面我加上userA的用户名。这样，userA就无法登录pop3服务器了。原因是“sense＝deny“。当然，你也可以配置成“sense＝allow“，这样在这个文件里的用户就成了可以登录的用户了，不过你得加入所有你想赋予登录权限的用户，因为不在这个文件中的用户将被DENY！

6.pam_permit.so – 和pam_deny.so正好相反，这个模块将永远返回真。自己从没用过，也许你可以告诉我为什么我需要这个模块？！

7.pam_rootok.so – root用户将通过认证。

8.pam_securetty.so – 将用/etc/securetty文件来检测root用户的登录来源，不在securetty文件中的来源一律禁止！

9.pam_tally.so – 主要用来记录，重置，和阻止失败的登录（次数）。

10.pam_wheel.so – 如果有这个模块，那个只有在wheel组里的用户可以得到root权限。

11.pam_xauth.so – 如果有这个模块，那么在su, sudo的时候，xauth的cookies将同时传到那个用户。（是不是想起来什么了？）

 

好了，冰山的一脚就到此结束了。希望这一脚能帮助你踏上PAM的高山。如果本文有什么错误，请多多指出。还有就是有什么配置PAM方面的经验，也希望大家一起来分享。更多，更详细的关于PAM的配置，请参看PAM的manpage和PAM模块的介绍，在/usr/share/doc/pam-version/txts,同时，网上资料：

The Linux-PAM System Administrators' Guide 

http://www.chinaunix.net/old_jh/4/390136.html

http://linux.chinaitlab.com/tool/530218.html