Linux-Pam总结

Pam 总结

概述

linux下PAM模块全称是Pluggable Authentication Module for linux（可插入式授权管理模块），该由Sun公司提供，在Linux中，PAM是可动态配置的，本地系统管理员可以自由选择应用程序如何对用户进行身份验证。PAM应用在许多程序与服务上，比如登录程序(login、su)的PAM身份验证（口令认证、限制登录），passwd强制密码，用户进程实时管理，向用户分配系统资源等。

简介

Linux-PAM（即linux可插入认证模块）是一套共享库,使本地系统管理员可以随意选择程序的认证方式。换句话说，不用(重新编写)重新编译一个包含PAM功能的应用程序，就可以改变它使用的认证机制，这种方式下，就算升级本地认证机制,也不用修改程序。

PAM使用配置/etc/pam.d/下的文件，来管理对程序的认证方式.应用程序 调用相应的配置文件，从而调用本地的认证模块.模块放置在/lib/security下，以加载动态库的形式进，像我们使用su命令时，系统会提示你输入root用户的密码.这就是su命令通过调用PAM模块实现的。

配置文件

PAM配置文件有下面两种写法:
1）写在/etc/pam.conf文件中，但centos6之后的系统中，这个文件就没有了。
2）将PAM配置文件放到 /etc/pam.d/ 目录下,其规则内容都是不包含 service 部分的，即不包含服务名称，而/etc/pam.d 目录下文件的名字就是服务名称。如： vsftpd,login等，只是少了最左边的服务名列。如：/etc/pam.d/sshd

如果配置文件放置在/etc/pam.d文件夹下，则配置文件中没有service选项，且配置文件的名字为service名字，文件名必须小写，配置语法区分大小写，配置规则格式为： service　　 type 　　control　　module-path　　module-arguments 服务名称　　类型　　 控制　　 模块路径　　　　模块参数

$ cat sshd                         
#%PAM-1.0   
auth       required     pam_sepermit.so   
auth       substack     password-auth   
auth       include      postlogin   
\# Used with polkit to reauthorize users in remote sessions   
-auth      optional     pam_reauthorize.so prepare   
account    required     pam_nologin.so   
account    include      password-auth   
password   include      password-auth   
\# pam_selinux.so close should be the first session rule   
session    required     pam_selinux.so close   
session    required     pam_loginuid.so   
\# pam_selinux.so open should only be followed by sessions to be executed in the use  
r context   
session    required     pam\_selinux.so open env\_params   
session    required     pam_namespace.so   
session    optional     pam_keyinit.so force revoke   
session    include      password-auth   
session    include      postlogin   
\# Used with polkit to reauthorize users in remote sessions   
-session   optional     pam_reauthorize.so prepare

类型 type

1. account manager (account): 提供账户服务验证，如账户密码是否过期，是否对该账户提供服务

2. authentication manager (auth)：负责对用户进行认证并建立用户凭证；通常该模块通过交互式方法进行认证，比如你应当输入密码证明你是你，但并非所有的认证都是该类型　　

3. **password manager (password)：进授权认证机制进行更新，如更改密码

4. **session manager (session)：当开启一个新会话时，该模块负责处理会话的准备任务，而当关闭某一个会话时，该模块负责善后工作，如卸载该用户home目录

对以上四种模块类型进一步补充说明：
auth：表示鉴别类接口模块类型用于检查用户和密码，并分配权限；
这种类型的模块为用户验证提供两方面服务。让应用程序提示用户输入密码或者其他标记，确认用户合法性；通过他的凭证许可权限，设定组成员关系或者其他优先权。

account：表示账户类接口，主要负责账户合法性检查，确认帐号是否过期，是否有权限登录系统等；
这种模块执行的是基于非验证的帐号管理。他主要用于限制/允许用户对某个服务的访问时间，当前有效的系统资源（最多可以多少用户），限制用户位置（例如：root只能通过控制台登录）。

多数情况下auth和account会一起用来对用户登录和使用服务的情况进行限制。这样的限制会更加完整。比如下面是一个具体的例子：login是一个应用程序。Login要完成两件工作——首先查询用户，然后为用户提供所需的服务，例如提供一个shell程序。通常Login要求用户输入名称和密码进行验证。当用户名输入的时候，系统自然会去比对该用户是否是一个合法用户，是否在存在于本地或者远程的用户数据库中。如果该账号确实存在，那么是否过期。这些个工作是由account接口来负责。

如果用户满足上述登录的前提条件，那么它是否具有可登录系统的口令，口令是否过期等。这个工作就要由auth接口来负责了，他通常会将用户口令信息加密并提供给本地（/etc/shadow）或者远程的(ldap，kerberos等)口令验证方式进行验证。

如果用户能够登录成功，证明auth和account的工作已经完成。但整个验证过程并没有完全结束。因为还有一些其他的问题没有得到确认。例如，用户能够在服务器上同时开启多少个窗口登录，用户可以在登录之后使用多少终端多长时间，用户能够访问哪些资源和不能访问哪些资源等等。也就是说登录之后的后续验证和环境定义等还需要其他的接口。这就是我们下面要提到的两组接口：

session：会话类接口。实现从用户登录成功到退出的会话控制；
处理为用户提供服务之前/后需要做的些事情。包括：开启/关闭交换数据的信息，监视目录等，设置用户会话环境等。也就是说这是在系统正式进行服务提供之前的最后一道关口。

password：口令类接口。控制用户更改密码的全过程。也就是有些资料所说的升级用户验证标记。

注意：上述接口在使用的时候，每行只能指定一种接口类型，如果程序需要多种接口的话，可在多行中分别予以规定。

控制 control

1. required：当使用此关键字的PAM模块验证失败，最终会导致PAM-API返回失败，但是会等到后续模块全部被验证后才会返回失败

2. requisite:该关键字与required使用方法类似，但是当PAM验证失败时，requisite会立刻向调用程序或父PAM桟返回失败值；该关键字可以防止攻击者获得系统已存在用户信息，通常该关键字用在重要的系统环境中

3. sufficient：如果该模块验证成功，而且该模块前无required模块验证失败，sufficient关键字将会向调用程序或者父PAM栈返回成功值而不会再调用后续的验证模块；当调用sufficient模块失败，PAM模块不会受sufficient模块失败影响，将会继续执行验证。

4. optional:当配置文件中仅有service+optional这一条规则时，optional模块才会起作用

5. include:将指定配置文件中所有的type类型作为参数包含在此控制语句中

6. substack:将指定配置文件中type作为参数包含在此控制语句中，和Include不同的是，在substack中完成任务或者die，只会影响substack内控制命令，不会影响完整的stack桟

规定如何处理PAM模块鉴别认证的结果，简而言之就是鉴别认证成功或者失败之后会发生什么事，如何进行控制。单个应用程序可以调用多种底层模块，通常称为“堆叠”。对应于某程序按照配置文件中出现顺序执行的所有模块成为“堆”，堆中的各模块的地位与出错时的处理方式由control_flag栏的取值决定，他的四种可能的取值分别为required、Requisite、sufficient或_optional：

required： 表示该行以及所涉及模块的成功是用户通过鉴别的必要条件。换句话说，只有当对应于应用程序的所有带 required标记的模块全部成功后，该程序才能通过鉴别。同时，如果任何带required标记的模块出现了错误，PAM并不立刻将错误消息返回给应用程序，而是在所有模块都调用完毕后才将错误消息返回调用他的程序。 反正说白了，就是必须将所有的模块都执行一次，其中任何一个模块验证出错，验证都会继续进行，并在执行完成之后才返回错误信息。这样做的目的就是不让用户知道自己被哪个模块拒绝，通过一种隐蔽的方式来保护系统服务。就像设置防火墙规则的时候将拒绝类的规则都设置为drop一样，以致于用户在访问网络不成功的时候无法准确判断到底是被拒绝还是目标网络不可达。

requisite： 与required相仿，只有带此标记的模块返回成功后，用户才能通过鉴别。不同之处在于其一旦失败就不再执行堆中后面的其他模块，并且鉴别过程到此结束，同时也会立即返回错误信息。与上面的required相比，似乎要显得更光明正大一些。

sufficient： 表示该行以及所涉及模块验证成功是用户通过鉴别的充分条件。也就是说只要标记为sufficient的模块一旦验证成功，那么PAM便立即向应用程序返回成功结果而不必尝试任何其他模块。即便后面的层叠模块使用了requisite或者required控制标志也是一样。当标记为sufficient的模块失败时，sufficient模块会当做 optional对待。因此拥有sufficient 标志位的配置项在执行验证出错的时候并不会导致整个验证失败，但执行验证成功之时则大门敞开。所以该控制位的使用务必慎重。

optional： 他表示即便该行所涉及的模块验证失败用户仍能通过认证。在PAM体系中，带有该标记的模块失败后将继续处理下一模块。也就是说即使本行指定的模块验证失败，也允许用户享受应用程序提供的服务。使用该标志，PAM框架会忽略这个模块产生的验证错误，继续顺序执行下一个层叠模块。

include： 表示在验证过程中调用其他的PAM配置文件。在RHEL系统中有相当多的应用通过完整调用/etc/pam.d/system-auth来实现认证而不需要重新逐一去写配置项。这也就意味着在很多时候只要用户能够登录系统，针对绝大多数的应用程序也能同时通过认证。

另外还有一种比较复杂的格式为value = action的语法来设置控制标志，标志之间会以空格分开。格式如下：

$ cat login    
#%PAM-1.0    
auth \[user\_unknown=ignore success=ok ignore=ignore default=bad\] pam\_securetty.so

其中value可以是下列Linux PAM库的返回值：
success、open_err、symbol_err、service_err、 system_err、buf_err、perm_denied、auth_err、cred_insufficient、authinfo_unavail、user_unknown、maxtries、new_authtok_reqd、acct_expired、 session_err、cred_unavail、cred_expired、cred_err、no_module_data、conv_err、 authtok_err、authtok_recover_err、authtok_lock_busy、authtok_disable_aging、 try_again、ignore、abort、authtok_expired、module_unknown、bad_item和default。

最后一个(default)能够用来设置上面的返回值无法表达的行为。

actionN可以是一个非负整数或者是下面的记号之一：ignore、ok、done、bad、die和reset。如果是非负整数J，就表示需要忽略后面J个同样类型的模块。通过这种方式，系统管理者可以更加灵活地设置层叠模块，模块的层叠路径由单个模块的反应决定。

** 关于这几个记号的详细解释：**
ignore：如果使用层叠模块，那么这个模块的返回值将被忽略，不会被应用程序知道。
bad：他表示这个返回码应该被看作是模块验证失败的标志。如果这个模块是层叠模块的第一个验证失败的模块，那么他的状态值就是整个层叠模块验证的状态值和结果。
die：终止层叠模块验证过程，立刻返回到应用程序。
ok：告诉PAM这个模块的返回值将直接作为所有层叠模块的返回值。也就是说，如果这个模块前面的模块返回状态是PAM_SUCCESS，那这个返回值就会覆盖前面的返回状态。注意：如果前面的模块的返回状态表示模块验证失败，那么不能使用这个返回值再加以覆盖。
done：终止后续层叠模块的验证，把控制权立刻交回应用程序。
reset：清除所有层叠模块的返回状态，从下一个层叠模块重新开始验证。

Path 路径

模块路径.即要调用模块的位置，也可是是默认模块的相对路径名. 如果是64位系统，一般保存在/lib64/security,如: pam_unix.so，同一个模块,可以出现在不同的类型中.它在不同的类型中所执行的操作都不相同.这是由于每个模块，针对不同的模块类型,编制了不同的执行函数。

参数

模块参数,即传递给模块的参数.参数可以有多个,之间用空格分隔开,如:password required pam_unix.so nullok obscure min=4 max=8 md5。

原理

当pam安装之后有两大部分：在/lib/security目录下的各种pam模块以及/etc/pam.d和/etc/pam.d目录下的针对各种服务和应用已经定义好的pam配置文件。当某一个有认证需求的应用程序需要验证的时候，一般在应用程序中就会定义负责对其认证的PAM配置文件。 例如： sshd 的配置文件中

$ cat /etc/ssh/sshd_config
...
UsePAM yes

下面我们将通过解读/etc/pam.d/system-auth文件予以说明。

首先要声明一点的是：system-auth是一个非常重要的pam配置文件，主要负责用户登录系统的认证工作。而且该文件不仅仅只是负责用户登录系统认证，其它的程序和服务通过include接口也可以调用到它，从而节省了很多重新自定义配置的工作。所以应该说该文件是系统安全的总开关和核心的pam配置文件。

#%PAM-1.0   
\# This file is auto-generated.   
\# User changes will be destroyed the next time authconfig is run.   
auth        required      pam_env.so   
auth        sufficient    pam\_unix.so nullok try\_first_pass   
auth        requisite     pam\_succeed\_if.so uid >= 1000 quiet_success   
auth        required      pam_deny.so   
    
account     required      pam_unix.so   
account     sufficient    pam_localuser.so   
account     sufficient    pam\_succeed\_if.so uid < 1000 quiet   
account     required      pam_permit.so   
    
password    requisite     pam\_pwquality.so try\_first\_pass local\_users_only retry=3   
authtok_type=   
password    sufficient    pam\_unix.so sha512 shadow nullok try\_first\_pass use\_autht  
ok   
password    required      pam_deny.so   
    
session     optional      pam_keyinit.so revoke   
session     required      pam_limits.so   
-session     optional      pam_systemd.so   
session     \[success=1 default=ignore\] pam\_succeed\_if.so service in crond quiet use  
_uid   
session     required      pam_unix.so

第一部分表示，当用户登录的时候，首先会通过auth类接口对用户身份进行识别和密码认证。所以在该过程中验证会经过几个带auth的配置项。

其中的第一步是通过pam_env.so模块来定义用户登录之后的环境变量， pam_env.so允许设置和更改用户登录时候的环境变量，默认情况下，若没有特别指定配置文件，将依据/etc/security/pam_env.conf进行用户登录之后环境变量的设置。

然后通过pam_unix.so模块来提示用户输入密码，并将用户密码与/etc/shadow中记录的密码信息进行对比，如果密码比对结果正确则允许用户登录，而且该配置项的使用的是“sufficient”控制位，即表示只要该配置项的验证通过，用户即可完全通过认证而不用再去走下面的认证项。不过在特殊情况下，用户允许使用空密码登录系统，例如当将某个用户在/etc/shadow中的密码字段删除之后，该用户可以只输入用户名直接登录系统。

下面的配置项中，通过pam_succeed_if.so对用户的登录条件做一些限制，表示允许uid大于1000的用户在通过密码验证的情况下登录，在Linux系统中，一般系统用户的uid都在1000之内，所以该项即表示允许使用useradd命令以及默认选项建立的普通用户直接由本地控制台登录系统。

最后通过pam_deny.so模块对所有不满足上述任意条件的登录请求直接拒绝，pam_deny.so是一个特殊的模块，该模块返回值永远为否，类似于大多数安全机制的配置准则，在所有认证规则走完之后，对不匹配任何规则的请求直接拒绝。

第二部分的三个配置项主要表示通过account账户类接口来识别账户的合法性以及登录权限。

第一行仍然使用pam_unix.so模块来声明用户需要通过密码认证。第二行承认了系统中uid小于1000的系统用户的合法性。之后对所有类型的用户登录请求都开放控制台。

第三部分会通过password口另类接口来确认用户使用的密码或者口令的合法性。第一行配置项表示需要的情况下将调用pam_pwquality.so来验证用户密码复杂度。如果用户输入密码不满足复杂度要求或者密码错，最多将在三次这种错误之后直接返回密码错误的提示，否则期间任何一次正确的密码验证都允许登录。

需要指出的是，pam_cracklib.so是一个常用的控制密码复杂度的pam模块，关于其用法举例我们会在之后详细介绍。之后带pam_unix.so和pam_deny.so的两行配置项的意思与之前类似。都表示需要通过密码认证并对不符合上述任何配置项要求的登录请求直接予以拒绝。不过用户如果执行的操作是单纯的登录，则这部分配置是不起作用的。

pam_pwquality.so 【待补充】

第四部分主要将通过session会话类接口为用户初始化会话连接。其中几个比较重要的地方包括，使用pam_keyinit.so表示当用户登录的时候为其建立相应的密钥环，并在用户登出的时候予以撤销。不过该行配置的控制位使用的是optional，表示这并非必要条件。之后通过pam_limits.so限制用户登录时的会话连接资源，相关pam_limit.so配置文件是/etc/security/limits.conf，默认情况下对每个登录用户都没有限制。关于该模块的配置方法在后面也会详细介绍。

常用模块

PAM模块	结合管理类型	说明
pam_unix.so	auth	提示用户输入密码,并与/etc/shadow文件相比对.匹配返回0
	account	检查用户的账号信息(包括是否过期等).帐号可用时,返回0.
	password	修改用户的密码. 将用户输入的密码,作为用户的新密码更新shadow文件
pam_shells.so	auth <br> account	如果用户想登录系统，那么它的shell必须是在/etc/shells文件中之一的shell
pam_deny.so	account <br>auth<br>password <br>session	该模块可用于拒绝访问
pam_permit.so	auth<br>account<br>password<br>session	模块任何时候都返回成功.
pam_securetty.so	auth	如果用户要以root登录时,则登录的tty必须在/etc/securetty之中.
pam_listfile.so	auth<br>account<br>password session	访问应用程的控制开关
pam_cracklib.so	password	这个模块可以插入到一个程序的密码栈中,用于检查密码的强度.
pam_limits.so	session	定义使用系统资源的上限，root用户也会受此限制，可以通过/etc/security/limits.conf或/etc/security/limits.d/*.conf来设定

使用说明

【待完善】

来源：oschina

链接：https://my.oschina.net/guopei/blog/3185275