thomassun
Linux-PAM(Linux下的密碼認證和安全机制)系統管理員指南(中文版)
The Linux-PAM 系统管理员指南
作者:Andrew G. Morgan, morgan@linux.kernel.org
翻译:孙国清(Thomas Sun),thomassun@yeah.net
DRAFT v0.71 1999/11/8 这个文档所涉的是系统管理员须知的关于Linux-PAM库的知识. 它涉及了设置PAM的正确语法并讨论维护一个可靠系统的正确的策略.
1. 介绍
Linux-PAM (Linux下的可插入式认证模组) 是一套共享函数库,允许系统管理员来决定应用程式如何识别用户.
换句话说,就是用不着(重写和)重新编译一个(支援PAM的)程式,就可以切换它所用的认证机制. 你可以整个的升级你的认证系统而不用去管应用程式本身.
传统上,当一个应用程序有身份识别的需求,它就不得不把某一种验证算法写进去. 例如,就传统的UN*X系统而言,核对使用者身份的方法就是要求用户输入正确的密码. 这密码,除了开头的两个字符作为"salt",剩下的是加密过的(经由crypt(3)). 接著用户被验证这个加密过的密码是否与他在密码档(就是/etc/passwd文件)中他的那笔记录的第二栏相符.在这样的系统里,绝大部份权限的授予是基于这种单一的认证机制. 权限决定于个人的识别码(uid)和不同群组的成员.服务和程式是否可用由个人和群组的识别码决定.传统上,群组关系经由/etc/group文件中的记录来赋予.
不幸的是,随着计算机速度的不断提高,再加上满世界的关于网路计算的介绍,使得象这样曾是安全的验证机制,变得易受攻击了.面对这样的现实,新的验证方法正在持续的开发中.
Linux-PAM项目的目标是把赋权部分的开发以可靠的合适的鉴定模式从软件中分离出来。这目标已经通过提供一组库函数实现了，应用程序可以用这些函数来请求验证某个用户。这个 PAM 由特定的系统文件配置,/etc/pam.conf (或者是在/etc/pam.d/里的一系列配置文件) 以经由特定的可用的认证模组来鉴定某个用户的请求。 这些个模组通常位于/usr/lib/security目录并且以可动态加载的目标文件的形式出现(参见 dlopen(3)).
2. 文中的说明
在继续阅读之前, 请记住本文假定提到的文件位于默认的目录。这个默认的目录我们遵循RFC(RFC-86.0,见 bibliography)中的约定。如果你正用一个支持PAM但是却选择以不同的方式发布这些文件的发布版的Linux(或是其他的OS) (Red Hat就是这样的发布版), 那你从文章中直接拷贝例子的时候就要注意一下了.
举个例子, where it is explicit, 本文假定PAM可加载目标文件(就是 模块)位于这个目录: /usr/lib/security/. 可是, Red Hat Linux, 为遵循Linux文件系统标准(the FSSTND),把这些文件放在/lib/security. 在使用本文的例子时请小心的做一些转换的工作。
3. 概观
For the uninitiated，我们开始于考虑一个例子。我们来说说一个应用程序提供一些服务给用户； login 就是这样的程序。 Login 做两件事，它首先确认提出请求的用户正是他们自己，第二步提供给他们所请求的服务： 就login而言服务即是一个命令行外壳（command shell）(如bash，tcsh，zsh之类。)以这个用户的身份去跑。
传统上，前一个步骤通过login提示用户输入密码然后确认系统是否同意登入；接着确认（就系统而言）用户确实是提出要求的那人。这类工作就是Linux-PAM的典型应用。
从应用程序员的角度看（在这个例子里就是写login程序的人）， Linux-PAM处理认证的工作——确认用户的身份。
Linux-PAM的弹性在于，你，系统管理员有权来决定实施怎样的验证方案。你有权来设定你的系统里的任何支持PAM的应用程序的验证方案。就是说，你可以将验证方案设计成单纯的信任>;任何人（pam_permit）到像偏执狂似的通过视网膜扫描，声音识别和一个密码！
举例说明你所面对的弹性，考虑以下情形：系统管理员（家中的父母）希望提高他的使用者（孩子们）的算术能力。她可以设置他们喜欢玩的“Shoot 'em up”（游戏，当然得支持PAM）通过提问小于12的一对随机数的乘积的办法来进行认证。很明显不管游戏本身如何，他们会很快学会乘法表。等他们再大些，认证可以升级到包括多位除法！（译者：我已经准备用这种办法来教我宝贝女儿学加减乘除了。）
Linux-PAM处理四种独立的（管理）工作。它们是： 认证管理； 帐号管理； 会话期间管理；和密码管理。 The association of the preferred management scheme with the behavior of an application is made with entries in the relevant Linux-PAM configuration file. 管理的功能由配置文件中指定的模块 来完成。这文件的语法在 below部分讨论。
下面的插图描述了Linux-PAM的整个组织结构。
+----------------+
| application: X |
+----------------+ / +----------+ +================+
| authentication-[---->;--/--] Linux- |--<--| PAM config file|
| + [----<--/--] PAM | |================|
|[conversation()][--+ / | | | X auth .. a.so |
+----------------+ | / +-n--n-----+ | X auth .. b.so |
| | | __| | | _____/
| service user | A | | |____,-----'
| | | V A
+----------------+ +------|-----|---------+ -----+------+
+---u-----u----+ | | |
| auth.... |--[ a ]--[ b ]--[ c ]
+--------------+
| acct.... |--[ b ]--[ d ]
+--------------+
| password |--[ b ]--[ c ]
+--------------+
| session |--[ e ]--[ c ]
+--------------+
By way of explanation, 图的左边表示一个应用程序:X. 这应用程序有和Linux-PAM 库的接口并且在认证方面没有什么特别之处. Linux-PAM 函数库 (图的中部) 查询PAM配置文件的内容并且装入适用于程序 X 的模块. 这些模块进入四个管理组( 图的中下部)中的一个,并且以它们出现在配置文件中的顺序堆叠起来 . 这些模组由Linux-PAM呼叫后,为应用程序执行不同的认证工作 . 需要用户提供或提供给用户的文本信息,可以通过使用应用程序提供的conversation函数来交换.
3.1 Getting started
以下段落由Seth Chaiklin供稿:
到现在为止,我们描述了PAM如何工作在一个理想世界里,
在这儿所有应用程序都被正确编写.
然而,到此时(1998年10月), 这距离现实还太远.
因此,在你试图把PAM用于你的系统时,还得考虑一些实际因素.
Why bother, is it really worth all the trouble?
如果你运行Linux作为单用户系统, 或者在一个所由用户都可信任的环境, 那么用PAM就没什么实际优势.
Ed: 事实上还是有一个好处, 你可以令认证变哑, 就象没有任何认证....像Win95.
在网络环境里, 很显然,关于用户你必需多想点, it is clear that you need to think a little more about how users etc., are authenticated:]
如果运行Linux作为服务器, 提供一些不同的服务 (e.g., 经由密码控制的WWW区域限制, PPP),
那PAM就有一些实际的和有趣的价值. 尤其是, 通过使用使用模块, PAM 能够使
一个程序经过几个不同的密码库来查找, 哪怕那个程序没有专为那密码库写的代码.
下面有一些例子Here are some examples of the possibilities
that this enables.
o Apache 有一个模块提供PAM服务. 认证特定的目录权限可以让PAM来控制，
这意味着，所有PAM能调用的模块都可以被Apache使用，包括RADIUS,NIS,NCP
(NCP用来经由Novell的密码库认证).
o pppd 有一个PAM化了的版本(来自 RedHat) 现在有可能用一系列的数据库来验证
ppp用户. 作为对基于Linux的密码库(/etc/passwd,/etc/shadow)的扩充, 你可以
用PAM模块来进行基于Novell密码库或NT(NTLM)密码库的认证.
o 以上两则例子可以有组合应用.想象一下你办公室/部门的用户已经经过用户名/密码
认证登入Novell或NT.如果你想要他在Linux下的应用也用相同的用户名/密码
(为PPP登入,web服务,或者只是普通的shell登入),你可以通过PAM进行基于这些已
存在的数据库(译者注:Novell的或者NT的)的用户认证,而无须在Linux和LAN服务器里
各自维护独立的数据库.
我可以让所有需要有用户认证的程序都来用PAM吗?
有的可以,有的不行.可以的是那些你能得到源代码,并且可以加入适当的PAM函数的程序.
不行的是那些你无法得到源代码,并且可执行程序没有加入PAM的功能.
也就是说, 如果一个程序打算要用PAM,那么它必须在程序里直接的包含PAM函数.
不这样做就不可能用PAM.
我怎么知道程序是否已经含有PAM的代码了呢?
一个快速的(但不总是可靠)的方法是执行ldd <程序>;
如果 libpam 和 libpam_misc 不在程序所需的函数库之列,那么它将不会用PAM.
然而,这两个函数库还是可能已经包含进程序了,不过问题依然存在,因为把PAM
写死在程序不会如你期望的工作.所以一个更可靠的方法是做一下的测试:
在/etc/pam.d目录里,需要为程序设有一个配置文件.具体的文件名是写死在程序里的.
通常和程序名一样,但却不总是这样.为举例说明,假设程序名字叫"pamprog",配置文件
是/etc/pam.d/pamprog.
在/etc/pam.d/pamprog里写这两行:
auth required pam_permit.so
auth required pam_warn.so
现在试着执行pamprog. 配置文件的第一行是说所有用户都被允许. 第二行会在你的
syslog 文件(或者其它你的syslog会写的文件) 里写一个warning.
如果这测试是成功的,那么你就知道你有一个"懂"pam的程序,并且你可以开始更有趣的工作:
决定如何在你的/etc/pam.d/pamprog里堆彻PAM模块.
4. Linux-PAM的设定档
Linux-PAM 给系统管理员提供了相当大的弹性来设定系统里程式的权限赋予. 由PAM控制的系统安全的本地配置可以包含在以下两个地方: 或者是一个单一的系统文件: /etc/pam.conf; 或者是/etc/pam.d/ 目录下的文件. 本章我们来讨论这些文件的语法和一般的选项.
4.1 设定档的语法
请注意, 在这些文件里 Linux-PAM 特有的符号是不区分大小写的. 而模块的路径,是大小写敏感的,因为它标识的是Linux下的文件的名字. 而任何模块参数的大小写分别由各个模块定义.
除以下的行之外,为系统管理员方便,还有两个特殊的字符: 注解由'#'开头,结束于行结束,另外,模块的描述行可以以 '/'脱字符延续到下一行.
通常/etc/pam.conf里的每一行有以下格式:
service-name module-type control-flag module-path arguments
接下来,我们来解释每个栏位的意思.另一种(也是常被采用的)设置Linux-PAM 的方法是通过/etc/pam.d/里的文件来实现.在我们解释完上面的那行之后, 我们就来讨论这种方法.
service-name
这笔记录相关的服务名称.通常这服务名称是特定应用程序的名字.比如, `ftpd', `rlogind' 和 `su' 这些. .
有一个保留的服务名称,它是用来定义默认的认证机制的. 它就是`OTHER',大小写无关.注意,当已经有为指定服务定义了模块,那么 `OTHER' 记录会被忽略.
module-type
模块的四种(目前是)类型.这四种类型是:
* auth; 这种模块类型确定有关用户认证的两方面. 第一,它确认用户就是他们自己,这通过指示应用程序提示用户输入密码或者其它证实身份的方法.第二,这类模块会赋予成员资格 Secondly, the module can grant group membership (independently of the /etc/groups file discussed above) or other privileges through its credential granting properties.
* account; 这些模块处理非认证级的帐号管理. 典型的用法是基于一天的不同时间段来限制/允许访问某服务,当前可用的系统资源 (最大用户数)或者限制特定用户---'root只能从控制台登录.
* session; 首先, 这类模块和一系列动作有关,指在用户得到/失去服务时要做的事. 这包括记录用户的登录/登出,挂载必须的目录等等.
* password; 这最后一种类型在更新用户的认证标志时需要. 通常,各个基于"质问/回答"(译注:指传统的用户名/密码的认证方法)的认证方法(auth)有一个对应的此模块.
control-flag
控制符用来指示当某一模块返回成功或失败时PAM如何动作. 既然模块可以被堆叠 (同种类型的模块按先后顺序执行,一个接一个), 控制符决定每个模块的重要程度.应用程序不会直接接收'/etc/pam.conf' 里列出的每一个模块的成功或失败的结果. 相应的是,它只从Linux-PAM接收一个 成功 或 失败 的结论. 这些模块的执行顺序就是它们在 /etc/pam.conf里的记录的顺序;排在前面的记录在排在后的记录之前被执行. 在Linux-PAM 0.60版本里, 这个control-flag 可以有两种语法来定义.
简单一些(也是过去的)语法是用一个限定词指示相关模块的重要程度. 有四个关键字: required, requisite, sufficient 和 optional.
Linux-PAM 将这四个关键字解释为:
* required; 需要的,这表明此模块返回成功值对于整个module-type的成功是必要的. 此模块的返回失败并不会传回给用户直到剩下的模块(同样module-type)都执行过.
* requisite; 必要的,类似 required, 只不过, 当这类模块返回失败时,整个控制会立刻回到应用程序. 返回值同第一个 需要的 或 必要的模块返回的失败. 注意,这标志可以用来防止 required or requisite module to fail. Note, this flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium. It is conceivable that such behavior might inform an attacker of valid accounts on a system. This possibility should be weighed against the not insignificant concerns of exposing a sensitive password in a hostile environment.
* sufficient; 充分的,这模块返回的成功会被认为已经 充分满足Linux-PAM 库确认这类模块(module-type)是成功的条件. 如果没有先前的requisite 模块返回了失败,那么不再会有其它'堆叠' 的模块被呼叫. (注意, 这种情况下,随后的requisite 模块就不会 被呼叫.). 这模块返回的失败不会看作是致命的错误而至影响应用程序从这module-type 得到成功的结果.
* optional; 可选的,正如这名字一样,此