可插拔认证模块 - PAM(Pluggable Authentication Modules) in Fedora 12

原文

本文翻译了Fedora文档 主页上，Fedora 12的系统安全指南(Security Guide)中第69至78页有关PAM(Pluggable Authentication Modules)的章节.

这些章节已经摘录出来，并附在后面，供参考。

在我快翻译完的时候，发现Redhat网站上已经有RHEL 5上的PAM的中文文档 了，晕倒!~~ ,不过还是坚持翻完吧。。。。

译文

Pluggable Authentication Modules (PAM) - 可插拔认证模块

授予用户某个系统的访问权限的程序，需要使用认证以验证彼此的身份，也就是要确证一个用户就是他所声称的那个人。

在过去，每个程序都有自己的一套用户认证的方法。不过在Fedora中，很多程序使用集中的认证机制，也就是可插拔认证模块(PAM)。

PAM采用可插拔、模块化的架构。基于这个架构，系统管理员在设置系统的认证策略时，就有了非常大的灵活性。

大多数情况下，对于支持PAM的应用程序来说，使用默认的PAM配置就足够了。不过有些时候，不可避免要去修改PAM的某个配置文件。不正确的PAM配置会危及系统的安全性，所以在对PAM配置文件任何修改之前，理解这些文件的架构是非常重要的。

PAM的优势

PAM具有以下优势：

• 体统了一个通用的认证模式：可以被各种应用程序使用
• 可以让系统管理员和应用程序开发人员对认证进行极其灵活的控制
• 为应用程序开发人员提供了一个统一的以及拥有丰富文档的认证库，让他们在开发应用的时候不必再创建自己的认证模式。

PAM的配置文件

/etc/pam.d/目录包含了所有支持PAM的应用程序的配置文件。早期版本的PAM使用一个单一的配置文件/etc/pam.conf。不过这个文件已经不再建议使用，而且只有在/etc/pam.d/目录不存在时才会被用到。

PAM 服务文件

每个支持PAM的应用程序在/etc/pam.d/目录下面都会有一个对应的配置文件。这个文件和它所控制访问的服务的名字是相同的。

支持PAM的程序负责定义他们的服务的名称并把他们自己的PAM配置文件安装到/etc/pam.d目录下面。比如linux登录程序(login)定义它的服务名称是login，并且要安装它的PAM配置文件:/etc/pam.d/login。

PAM配置文件的格式

PAM配置文件包含了一组如下的指令：
<模块接口> <控制标志> <模块名称> <模块参数>
下面，我们将对每一部分进行解释。

模块接口

目前共有4种PAM模块接口，对应到认证过程中的不同方面。

• auth —该接口用来认证用户。例如，可以使用它来请求并验证用户密码的有效性，也可以用来设置凭证，比如组的成员身份或者Kerberos票据
• account — 该接口用来验证是否允许访问。例如，它可以检查用户的账户是否过期或者是否允许某个用户在某个时间段登录。
• password — 该接口用于用户密码修改。
• session — 该接口用来配置和管理用户会话，还可以执行附加的任务。在允许用户访问时要用到这些任务，比如挂载用户的home目录以及准备好用户的邮箱。

在一个PAM配置文件中，模块接口是第一个需要定义的字段。例如，下面就是一个典型的配置行：
auth required pam_unix.so

这行配置告诉PAM使用pam_unix.so模块提供的auth接口。
注意 ：

一个单独的模块可以提供任意或者全部的接口。比如pam_unix.so就提供了全部的4个模块接口。

叠加使用模块接口

模块接口指令可以叠加起来使用，也就是让一个接口基于另一个，这样就可以使用多个接口来一起实现某个目的。如果一个模块的控制标志是"sufficient"或者"requisite"(下面的章节会详细介绍这些标志)，那么这些模块在配置文件中的罗列顺序，对于认证的过程来说，是很重要的.

有时候，管理员，需要在某些特定的条件下，才允许一个用户进行认证之前。叠加接口使得实现这种需要变得简单起来。例如，reboot命令一般需要几个叠加的模块，就像在它的配置文件中所设定的：
[root@MyServer ~]# cat /etc/pam.d/reboot
#%PAM-1.0
auth sufficient pam_rootok.so
auth required pam_console.so
#auth include  system-auth
account required pam_permit.so

• 第一行是注释，不会被处理。
• auth sufficient pam_rootok.so —  这一行使用pam_rootok.so模块检查当前用户是否是root（检查该用户的UID是否为0）。如果是root用户的话，下面的其他模块就不再考虑检查，而是直接允许执行reboot命令；否则，将会继续下一个模块的验证。
• auth required pam_console.so — 这一行使用pam_console.so模块来验证用户。如果用户已经登录到控制台(console)，pam_console.so会检查在/etc/security/console.apps/目录下面是否存在跟该服务命令(reboot)名称相同的文件。如果存在的话，验证成功，然后继续验证下一个模块。
• #auth include system-auth — 注释，不会被处理。
• account required pam_permit.so —  这一行使用pam_permit.so模块。这个模块会允许root用户以及任何已经登录到console的用户重启(reboot)系统。

控制标志

PAM模块在被调用的时候，会产生一个成功或者失败的结果。控制标志指示PAM应该怎么处理这个结果。对于按照某种顺序叠加起来的几个模块，它们的成功或者失败对于整个认证用户是否能使用服务的过程，可能有不同的重要性，这就取决于它们的控制标志。

共有4中预先定义好的控制标志：

• required —  这个模块必须返回成功，认证过程才可以继续。如果这个模块失败的话，并不会立即通知用户，而是要等到全部模块都被执行完以后。
• requisite — 这个模块必须返回成功，认证过程才可以继续。但是如果失败的话，会立即通知用户，在第一次进行哪个标志为required或者requisite的模块验证的时候失败。
• sufficient — 如果模块返回失败，将被忽略。不过，如果返回成功，而且前面已经验证过的标志位required的模块都没有返回失败，那么不会再继续验证后面的模块，而是直接告知应用程序验证成功。
• optional — 这个模块的返回结果将被忽略，除非在模块接口中，只有它自己一个模块，那么它必须返回成功，才能使用户成功通过验证。

现在PAM已经有了新的控制标志语法，可以对认证过程进行更加精确的控制。

有关新语法的详细内容，请参考pam.d的man page，以及PAM文档（位于/usr/share/doc/pam-<version-number>/目录下面，其中<version-number>是你的系统中运行的PAM的版本号）。

重要提示
标志为required的模块的调用顺序是无关紧要的。不过当使用sufficient和requisite标志的时候，顺序就变得重要起来。

 

模块名称

模块名称为PAM提供了包含指定接口的模块的名字。在旧的Fedora版本中，需要在PAM配置文件中给出模块的完整路径。不过随着multilib系统（在/lib64/security/目录下面存放64位的PAM模块）的出现，PAM模块路径中，除了文件名，其他的目录部分就可以省略了，因为应用程序编译时会被链接到适当版本的libpam，后者会找到正确版本的模块。

模块参数

在某些模块认证过程中，PAM通过参数来向该模块传递信息。

以pam_userdb.so为例，它使用存储在Berkeley DB文件中的信息来认证用户（Berkeley DB是一个开源的可以内嵌到许多应用程序里面的数据库系统）。这个模块就是通过参数db来指定使用哪个Berkeley DB数据库。

下面是一个典型的pam_userdb.so配置行。<path-to-file>是Berkeley DB数据库文件的完整路径：

auth required pam_userdb.so db=<path-to-file>

非法的参数一般都会被忽略，并且不会影响到PAM模块的成功或者失败。不过还是有一些模块，在碰到非法参数的时候，会返回失败。大多数模块会把错误信息保存到/var/log/secure文件。

PAM配置文件示例

下面是一个PAM配置文件的例子：
#%PAM-1.0
auth  required  pam_securetty.so
auth  required  pam_unix.so nullok
auth  required  pam_nologin.so
account  required  pam_unix.so
password required  pam_cracklib.so retry=3
password required  pam_unix.so shadow nullok use_authtok
session required  pam_unix.so

• 第一行以#开始，表明是注释行。
• 第2到4行，叠加使用了3个模块进行登录认证。
  auth required pam_securetty.so — 这个模块确保在一个用户试图以root登录的时候，他使用的tty终端包含在/etc/securetty文件中，如果存在/etc/securetty文件的话。如果并没有包含该tty，任何以root来登录的企图都会失败，并会得到登录错误的消息。
  auth required pam_unix.so nullok —这个模块会提示用户输入密码，然后把它和保存在/etc/shadow文件中的加密密码进行对比，如果存在/etc/shadow文件的话。nullok参数告诉pam_unix.so模块允许空密码。
  auth required pam_nologin.so — 这是认证的最后一步。它会检查是否存在/etc/nologin文件。如果存在这个文件，并且登录的用户如是root的话，认证将会失败。
  

  注意

  在这个例子中，所有的三个auth模块都会被检查，即使第一个模块返回失败。这样可以防止用户知道他们的登录是在哪个阶段失败的。如果一个攻击者掌握了这些信息的话，他们就会很容易的据此推断如何破解这个系统。

• account required pam_unix.so — 这个模块可以进行任何必要的账户验证。例如，如果启用shadow密码的话，pam_unix.so中的account接口就会检查该用户的账户是否过期，或者用户是否还没有在允许的宽限期内修改密码。
• password required pam_cracklib.so retry=3 —如果用户的密码已经过期，pam_crack.so模块的密码组件就会提示用户设置新的密码。然后它会检查新设置的密码是否会被基于字典的破解程序轻易破解。参数retry=3指定用户共有3次机会去设置一个强健的密码。
• password required pam_unix.so shadow nullok use_authtok — 这一行指定，如果程序要修改用户密码的话，它应该使用pam_unix.so模块中的password接口。
  shadow参数告诉这个模块，在更新用户密码的时候要使用shadow密码。
  nullok参数告诉模块允许用户修改原来的空密码。否则的话，如果用户原来的密码为空，会认为账户已经被锁定。
  最后的use_authtok参数，为我们提供了一个很好的例子，说明了在叠加使用模块时顺序的重要性。这个参数告诉模块不要提示用户输入新密码，而是使用前面模块的password接口记录下的新密码。通过这种方式，所有的新密码在被接受之前，都必须通过pam_cracklib.so模块的检验，以确保密码是安全的。
• session required pam_unix.so — 最后一行指示由pam_unix.so模块的session接口来管理用户会话。在每个会话的开始和结束，这个模块会把用户名和请求的服务类型记录到/var/log/secure文件中。可以叠加其他的session接口的模块，来提供附加功能。

创建PAM模块

可以随时创建或者增加新的PAM模块，让支持PAM的应用程序使用。

比如，开发人员可以创建一种一次性密码的生成方法，并写一个PAM模块来支持这个方法。支持PAM的程序可以立即使用这个新的模块的password接口，而不需要重新编译或者修改代码。

这就让开发人员和系统管理员混合搭配使用以及测试不同程序的认证方法，而不需要重新编译这些程序。

/usr/share/doc/pam-<version-number>/目录中包含了如何开发PAM模块的文档。<version-number>是系统使用的PAM的版本号。

PAM以及管理员用户身份的缓存

Fedora中的一些图形化管理工具会使用pam_timestamp.so模块，可以让用户的权限提升最长5分钟的时间。理解该机制的工作原理是很重要的，因为如果在pam_timestamp.so模块有效的期间，用户离开他的计算机的话，那么任何能够物理接触该用户终端的人都可以对机器进行操作。

在PAM的timestamp机制中，图形化的管理程序在启动的时候会要求用户输入root密码。如果密码正确的话，pam_timestamp.so模块就会创建一个时间戳文件，默认的位置是/var/run/sudo/目录。如果时间戳文件已经存在的话，管理程序就不会要求输入root密码，而pam_timestamp.so模块会刷新这个文件，额外增加5分钟时间，让该用户在这段时间内拥有管理员权限。

通过检查/var/run/sudo/<user>文件，可以检验这个时间戳文件的实际状态。对于台式机，相关的文件是 unknown:root。如果这个文件存在而且它的时间戳不早于5分钟的话，用户的身份就是有效的。

如果时间戳文件存在，系统面板的通知区域中会出现一个验证图标( )。

清除Timestamp文件

在关闭一个时间戳处于激活状态的控制台前，最好销毁时间戳文件。要在图形化环境中销毁时间戳文件，点击面板中的验证图标。在出现的对话框中（如下所示），点击Forget Authorization 按钮就可以销毁激活的时间戳文件了。

关于PAM时间戳文件，要注意以下的问题：

• 如果使用ssh远程登录到系统，要使用命令/sbin/pam_timestamp_check -k root来销毁时间戳文件。
• 在运行命令/sbin/pam_timestamp_check -k root的时候，要使用跟用来运行特权应用程序的相同的那个终端窗口。
• 你必须使用跟调用pam_timestamp.so相同的那个用户来登录，来运行命令/sbin/pam_timestamp_check -k root。不要使用root用户来运行这个命令。
• 如果你想清除桌面上的用户身份信息，但又不想使用验证图标的Forget Authorization，可以使用如下命令：
  /sbin/pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/null
  如果这个命令运行失败的话，只会清除你用来运行命令的那个pty的用户身份信息。

关于使用pam_timestamp_check销毁时间戳文件的更多信息，请参考pam_timestamp_check的man帮助。

常用的 pam_timestamp指令

pam_timestamp.so模块可以接受多个指令。下面是其中两个最常用的选项：

• timestamp_timeout — 指定时间戳文件的有效期（以秒为单位）。默认值是300秒，也就是5分钟。
• timestampdir — 指定时间戳文件的存储目录。默认会使用目录/var/run/sudo/。

请参考Fedora12安全指南的第2.9.9.1章节-已安装的防火墙文档，来获取关于pam_timestamp.so模块的更多信息。

PAM和设备的所有权

在Fedora中，第一登录到物理控制台的用户可以管理某些设备并执行特定的某些任务，而这些任务通常只有root用户才能执行。这是通过pam_console.so这个模块来控制的。
设备的所有权

当用户登录到Fedora系统的时候，pam_console.so模块将被login进程或者图形登录程序（gdm, kdm以及xdm）调用。如果他是是第一个登录到物理控制台的用户(称为控制台用户)，这个模块就会授予他一些设备的所有者权限，而一般情况下，这些设备都是root用户拥有的。这个控制台用户一直拥有这些设备，直到他的最后一个本地会话结束。在这个用户注销登录后，这些设备的所有者会恢复成root用户。

这些设备包括，但不限于，声卡，软驱和光驱。
这样就允许本地用户直接管理这些设备，而不需要先获得root权限，从而简化了控制台用户执行某些日常任务的复杂性。
通过编辑下列文件，你可以修改受pam_console.so控制的设备列表：

• /etc/security/console.perms
• /etc/security/console.perms.d/50-default.perms

你可以修改那些并没有在上述文件中列出的设备的权限或者覆盖指定的默认值。你应该创建一个新文件（例如,xx-name.perms）来输入需要修改的值，而不是改动50-default.perms文件。新的默认文件的名字必须以大于50的数字开始（例如51-default.perms）,这样就会覆盖在50-default.perms设定的值。

警告

如果修改了gdm,kdm或者xdm的配置文件以允许远程用户登录，而且主机的运行级别为5，最好把/etc/security/console.perms中的<console> 和<xconsole>修改为下面的值：
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0/.[0-9] :0

<xconsole>=:0/.[0-9] :0
这样可以防止远程用户获取主机上设备和受限程序的访问权。

如果修改了gdm,kdm或者xdm的配置文件以允许远程用户登录，而且主机的运行级别不是5，最好在/etc/security/console.perms中，删除整个<xconsole>指令，并把<console>修改为下面的值：

<console>=tty[0-9][0-9]* vc/[0-9][0-9]*

应用程序访问

控制台用户同时还会获得某些程序的使用权，这些程序在/etc/security/console.apps/ 目录下面配置。这个目录下面的配置文件让控制台用户可以运行/sbin和/usr/sbin目录下面的某些程序。配置文件拥有跟它所有配置的应用程序相同的名字。

一组显著的控制台用户能够运行的程序包括3个用来关闭或者重启系统的命令：

• /sbin/halt
• /sbin/reboot
• /sbin/poweroff

它们都支持PAM，在使用的时候都会调用pam_console.so这个模块。
请参考Fedora12安全指南的第2.9.9.1章节-已安装的防火墙文档，来获取更多信息。

附加资源

下面的资源进一步解释了使用和配置PAM的方法。除了这些资源，还可以阅读系统上的PAM配置文件来更好的理解它们的结构。

已安装的PAM文档

• PAM相关的man page — 多个跟PAM相关的不同应用程序和配置文件都有man帮助。下面列出了其中比较重要的几个：
  配置文件
  • pam — 很好的PAM入门资料，介绍了PAM配置文件的结构和目的。
    请注意，这个man page讨论了/etc/pam.conf文件以及在/etc/pam.d/目录下面的单个配置文件。Fedora默认使用/etc/pam.d/目录下面的单个配置文件，而忽略/etc/pam.conf，即使这个文件存在。
  • pam_console — 介绍了pam_console.so模块的目的，还描述了PAM 配​置​文​件​中​配置项的适​当​语​法。
  • console.apps — 介绍了/etc/security/console.apps配置文件可用的配置格式和选项。这个配置文件定义了哪些应用程序可以被PAM分配的控制台用户使用。
  • console.perms — 介绍了/etc/security/console.perms配置文件可用的配置格式和选项。这个配置文件指定了PAM分配的控制台用户的权限。
  • pam_timestamp — 描述了pam_timestamp.so模块。
• /usr/share/doc/pam-<version-number> — 包括了系统管理员指南，模块编写人员手册以及应用程序开发人员手册，还有PAM标准(DEC-RFC 86.0)的一个副本。其中<version-number>是PAM的版本号。
• /usr/share/doc/pam-<version-number>/txts/README.pam_timestamp — 包含了pam_timestamp.so模块的信息, 其中<version-number>是PAM的版本号。

有用的PAM网站

http://www.kernel.org/pub/linux/libs/pam/ — 这是Linux-PAM项目的主要发布站点，包括了各种PAM模块的信息，FAQ以及额外的PAM文档。

注意

这面网站中的文档是为最新发布的PAM版本编写的，可能跟包含在Fedora中的PAM备案本不是100%一致。

附录-原文摘录

Pluggable Authentication Modules (PAM)

Programs that grant users access to a system use authentication to verify each other's identity (that is,to establish that a user is who they say they are).

Historically, each program had its own way of authenticating users. In Fedora, many programs are configured to use a centralized authentication mechanism called Pluggable Authentication Modules (PAM).

PAM uses a pluggable, modular architecture, which affords the system administrator a great deal of flexibility in setting authentication policies for the system.

In most situations, the default PAM configuration file for a PAM-aware application is sufficient. Sometimes, however, it is necessary to edit a PAM configuration file. Because misconfiguration of PAM can compromise system security, it is important to understand the structure of these files before making any modifications. Refer to Section 2.5.3, “PAM Configuration File Format” for more information.

Advantages of PAM

PAM offers the following advantages:

• a common authentication scheme that can be used with a wide variety of applications.
• significant flexibility and control over authentication for both system administrators and application developers.
• a single, fully-documented library which allows developers to write programs without having to create their own authentication schemes.

 

PAM Configuration Files

The /etc/pam.d/ directory contains the PAM configuration files for each PAM-aware application. In earlier versions of PAM, the /etc/pam.conf file was used, but this file is now deprecated and is only used if the /etc/pam.d/ directory does not exist.

PAM Service Files

Each PAM-aware application or service has a file in the /etc/pam.d/ directory. Each file in this directory has the same name as the service to which it controls access.

The PAM-aware program is responsible for defining its service name and installing its own PAM configuration file in the /etc/pam.d/ directory. For example, the login program defines its service name as login and installs the /etc/pam.d/login PAM configuration file.

PAM Configuration File Format

Each PAM configuration file contains a group of directives formatted as follows:
<module interface>  <control flag>   <module name>   <module arguments>
Each of these elements is explained in the following sections.

Module Interface

Four types of PAM module interface are currently available. Each of these corresponds to a different aspect of the authorization process:

• auth — This module interface authenticates use. For example, it requests and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships or Kerberos tickets.
• account — This module interface verifies that access is allowed. For example, it may check if a user account has expired or if a user is allowed to log in at a particular time of day.
• password — This module interface is used for changing user passwords.
• session — This module interface configures and manages user sessions. Modules with this interface can also perform additional tasks that are needed to allow access, like mounting a user's home directory and making the user's mailbox available.

In a PAM configuration file, the module interface is the first field defined. For example, a typical line in a configuration may look like this:
auth required pam_unix.so
This instructs PAM to use the pam_unix.so module's auth interface

Note
An individual module can provide any or all module interfaces. For instance, pam_unix.so provides all four module interfaces.

Stacking Module Interfaces

Module interface directives can be stacked, or placed upon one another, so that multiple modules are used together for one purpose. If a module's control flag uses the "sufficient" or "requisite" value (refer to Section 2.5.3.2, “Control Flag” for more information on these flags), then the order in which the modules are listed is important to the authentication process.

Stacking makes it easy for an administrator to require specific conditions to exist before allowing the user to authenticate. For example, the reboot command normally uses several stacked modules, as seen in its PAM configuration file:
[root@MyServer ~]# cat /etc/pam.d/reboot
#%PAM-1.0
auth sufficient pam_rootok.so
auth required pam_console.so
#auth include  system-auth
account required pam_permit.so

• The first line is a comment and is not processed.
• auth sufficient pam_rootok.so — This line uses the pam_rootok.so module to check whether the current user is root, by verifying that their UID is 0. If this test succeeds, no other modules are consulted and the command is executed. If this test fails, the next module is consulted.
• auth required pam_console.so — This line uses the pam_console.so module to attempt to authenticate the user. If this user is already logged in at the console, pam_console.so checks whether there is a file in the /etc/security/console.apps/ directory with the same name as the service name (reboot). If such a file exists, authentication succeeds and control is passed to the next module.
• #auth include system-auth — This line is commented and is not processed.
• account required pam_permit.so — This line uses the pam_permit.so module to allow the root user or anyone logged in at the console to reboot the system.

Control Flag

All PAM modules generate a success or failure result when called. Control flags tell PAM what do with the result. Modules can be stacked in a particular order, and the control flags determine how important the success or failure of a particular module is to the overall goal of authenticating the user to the service.

There are four predefined control flags:

• required — The module result must be successful for authentication to continue. If the test fails at this point, the user is not notified until the results of all module tests that reference that interface are complete.
• requisite — The module result must be successful for authentication to continue. However, if a test fails at this point, the user is notified immediately with a message reflecting the first failed required or requisite module test.
• sufficient — The module result is ignored if it fails. However, if the result of a module flagged sufficient is successful and no previous modules flagged required have failed, then no other results are required and the user is authenticated to the service.
• optional — The module result is ignored. A module flagged as optional only becomes necessary for successful authentication when no other modules reference the interface.

A newer control flag syntax that allows for more precise control is now available for PAM.

The pam.d man page, and the PAM documentation, located in the /usr/share/doc/pam-<version-number>/ directory, where <version-number> is the version number for PAM on your system, describe this newer syntax in detail.

Important
The order in which required modules are called is not critical. Only the sufficient and requisite control flags cause order to become important.

Module Name

The module name provides PAM with the name of the pluggable module containing the specified module interface. In older versions of Fedora, the full path to the module was provided in the PAM configuration file. However, since the advent of multilib systems, which store 64-bit PAM modules in the /lib64/security/ directory, the directory name is omitted because the application is linked to the appropriate version of libpam, which can locate the correct version of the module.

Module Arguments

PAM uses arguments to pass information to a pluggable module during authentication for some modules.
For example, the pam_userdb.so module uses information stored in a Berkeley DB file to authenticate the user. Berkeley DB is an open source database system embedded in many applications. The module takes a db argument so that Berkeley DB knows which database to use for the requested service.
The following is a typical pam_userdb.so line in a PAM configuration. The <path-to-file> is the full path to the Berkeley DB database file:
auth required pam_userdb.so db=<path-to-file>

Invalid arguments are generally ignored and do not otherwise affect the success or failure of the PAM module. Some modules, however, may fail on invalid arguments. Most modules report errors to the /var/log/secure file.

Sample PAM Configuration Files

The following is a sample PAM application configuration file:
#%PAM-1.0
auth  required  pam_securetty.so
auth  required  pam_unix.so nullok
auth  required  pam_nologin.so
account  required  pam_unix.so
password required  pam_cracklib.so retry=3
password required  pam_unix.so shadow nullok use_authtok
session required  pam_unix.so

• The first line is a comment, indicated by the hash mark (#) at the beginning of the line.
• Lines two through four stack three modules for login authentication.
  auth required pam_securetty.so — This module ensures that if the user is trying to log in as root, the tty on which the user is logging in is listed in the /etc/securetty file, if that file exists.
  If the tty is not listed in the file, any attempt to log in as root fails with a Login incorrect message.
  auth required pam_unix.so nullok — This module prompts the user for a password and then checks the password using the information stored in /etc/passwd and, if it exists, /etc/shadow.
  The argument nullok instructs the pam_unix.so module to allow a blank password.
  

  Note

  In this example, all three auth modules are checked, even if the first auth module fails. This prevents the user from knowing at what stage their authentication failed. Such knowledge in the hands of an attacker could allow them to more easily deduce how to crack the system.
• auth required pam_nologin.so — This is the final authentication step. It checks whether the /etc/nologin file exists. If it exists and the user is not root, authentication fails.
• account required pam_unix.so — This module performs any necessary account verification. For example, if shadow passwords have been enabled, the account interface of the pam_unix.so module checks to see if the account has expired or if the user has not changed the password within the allowed grace period.
• password required pam_cracklib.so retry=3 — If a password has expired, the password component of the pam_cracklib.so module prompts for a new password. It then tests the newly created password to see whether it can easily be determined by a dictionary-based password cracking program.
  The argument retry=3 specifies that if the test fails the first time, the user has two more chances to create a strong password.
• password required pam_unix.so shadow nullok use_authtok — This line specifies that if the program changes the user's password, it should use the password interface of the pam_unix.so module to do so.
  The argument shadow instructs the module to create shadow passwords when updating a user's password.
  The argument nullok instructs the module to allow the user to change their password from a blank password, otherwise a null password is treated as an account lock.
  The final argument on this line, use_authtok, provides a good example of the importance of order when stacking PAM modules. This argument instructs the module not to prompt the user for a new password. Instead, it accepts any password that was recorded by a previous password module. In this way, all new passwords must pass the pam_cracklib.so test for secure passwords before being accepted.
• session required pam_unix.so — The final line instructs the session interface of the pam_unix.so module to manage the session. This module logs the user name and the service type to /var/log/secure at the beginning and end of each session. This module can be supplemented by stacking it with other session modules for additional functionality.

Creating PAM Modules

You can create or add new PAM modules at any time for use by PAM-aware applications.

For example, a developer might create a one-time-password creation method and write a PAM module to support it. PAM-aware programs can immediately use the new module and password method without being recompiled or otherwise modified.

This allows developers and system administrators to mix-and-match, as well as test, authentication methods for different programs without recompiling them.

Documentation on writing modules is included in the /usr/share/doc/pam-<version-number>/ directory, where <version-number> is the version number for PAM on your system.

PAM and Administrative Credential Caching

A number of graphical administrative tools in Fedora provide users with elevated privileges for up to five minutes using the pam_timestamp.so module. It is important to understand how this mechanism works, because a user who walks away from a terminal while pam_timestamp.so is in effect leaves the machine open to manipulation by anyone with physical access to the console.

In the PAM timestamp scheme, the graphical administrative application prompts the user for the root password when it is launched. When the user has been authenticated, the pam_timestamp.so module creates a timestamp file. By default, this is created in the /var/run/sudo/ directory. If the timestamp file already exists, graphical administrative programs do not prompt for a password. Instead, the pam_timestamp.so module freshens the timestamp file, reserving an extra five minutes of unchallenged administrative access for the user.

You can verify the actual state of the timestamp file by inspecting the /var/run/sudo/<user> file.

For the desktop, the relevant file is unknown:root. If it is present and its timestamp is less than five minutes old, the credentials are valid.

The existence of the timestamp file is indicated by an authentication icon, which appears in the notification area of the panel( ).

Removing the Timestamp File

Before abandoning a console where a PAM timestamp is active, it is recommended that the timestamp file be destroyed. To do this from a graphical environment, click the authentication icon on the panel. This causes a dialog box to appear. Click the Forget Authorization button to destroy the active timestamp file.

You should be aware of the following with respect to the PAM timestamp file:

• If logged in to the system remotely using ssh, use the /sbin/pam_timestamp_check -k root command to destroy the timestamp file.
• You need to run the /sbin/pam_timestamp_check -k root command from the same terminal window from which you launched the privileged application.
• You must be logged in as the user who originally invoked the pam_timestamp.so module in order to use the /sbin/pam_timestamp_check -k command. Do not log in as root to use this command.
•  If you want to kill the credentials on the desktop (without using the Forget Authorization action on the icon), use the following command:
  /sbin/pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/null
  Failure to use this command will only remove the credentials (if any) from the pty where you run the command.

Refer to the pam_timestamp_check man page for more information about destroying the timestamp file using pam_timestamp_check.

Common pam_timestamp Directives

The pam_timestamp.so module accepts several directives. The following are the two most commonly used options:

• timestamp_timeout — Specifies the period (in seconds) for which the timestamp file is valid. The default value is 300 (five minutes).
• timestampdir — Specifies the directory in which the timestamp file is stored. The default value is /var/run/sudo/.

Refer to Section 2.9.9.1, “Installed Firewall Documentation” for more information about controlling the pam_timestamp.so module.

PAM and Device Ownership

In Fedora, the first user who logs in at the physical console of the machine can manipulate certain devices and perform certain tasks normally reserved for the root user. This is controlled by a PAM module called pam_console.so.
Device Ownership

When a user logs in to a Fedora system, the pam_console.so module is called by login or the graphical login programs, gdm, kdm, and xdm. If this user is the first user to log in at the physical console — referred to as the console user — the module grants the user ownership of a variety of devices normally owned by root. The console user owns these devices until the last local session for that user ends. After this user has logged out, ownership of the devices reverts back to the root user.

The devices affected include, but are not limited to, sound cards, diskette drives, and CD-ROM drives.
This facility allows a local user to manipulate these devices without obtaining root access, thus simplifying common tasks for the console user.
You can modify the list of devices controlled by pam_console.so by editing the following files:

• /etc/security/console.perms
• /etc/security/console.perms.d/50-default.perms

You can change the permissions of different devices than those listed in the above files, or override the specified defaults. Rather than modify the 50-default.perms file, you should create a new file (for example, xx-name.perms) and enter the required modifications. The name of the new default file must begin with a number higher than 50 (for example, 51-default.perms). This will override the defaults in the 50-default.perms file.

Warning

If the gdm, kdm, or xdm display manager configuration file has been altered to allow remote users to log in and the host is configured to run at runlevel 5, it is advisable to change the <console> and <xconsole> directives in the /etc/security/
console.perms to the following values:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0/.[0-9] :0

<xconsole>=:0/.[0-9] :0
This prevents remote users from gaining access to devices and restricted applications on the machine.

If the gdm, kdm, or xdm display manager configuration file has been altered to allow remote users to log in and the host is configured to run at any multiple user runlevel other than 5, it is advisable to remove the <xconsole> directive entirely and change the <console> directive to the following value:

<console>=tty[0-9][0-9]* vc/[0-9][0-9]*

Application Access

The console user also has access to certain programs configured for use in the /etc/security/console.apps/ directory.

This directory contains configuration files which enable the console user to run certain applications in /sbin and /usr/sbin.
These configuration files have the same name as the applications that they set up.

One notable group of applications that the console user has access to are three programs that shutdown or reboot the system:

• /sbin/halt
• /sbin/reboot
• /sbin/poweroff

Because these are PAM-aware applications, they call the pam_console.so module as a requirement for use.
Refer to Section 2.9.9.1, “Installed Firewall Documentation” for more information.

Additional Resources

The following resources further explain methods to use and configure PAM. In addition to these resources, read the PAM configuration files on the system to better understand how they are structured.

Installed PAM Documentation

• PAM-related man pages — Several man pages exist for the various applications and configuration files involved with PAM. The following is a list of some of the more important man pages.
  Configuration Files
  • pam — Good introductory information on PAM, including the structure and purpose of the PAM configuration files.
    Note that this man page discusses both /etc/pam.conf and individual configuration files in the /etc/pam.d/ directory. By default, Fedora uses the individual configuration files in the /etc/pam.d/ directory, ignoring /etc/pam.conf even if it exists.
  • pam_console — Describes the purpose of the pam_console.so module. It also describes the appropriate syntax for an entry within a PAM configuration file.
  • console.apps — Describes the format and options available in the /etc/security/console.apps configuration file, which defines which applications are accessible by the console user assigned by PAM.
  • console.perms — Describes the format and options available in the /etc/security/console.perms configuration file, which specifies the console user permissions assigned by PAM.
  • pam_timestamp — Describes the pam_timestamp.so module.
• /usr/share/doc/pam-<version-number> — Contains a System Administrators' Guide, a Module Writers' Manual, and the Application Developers' Manual, as well as a copy of the PAM standard, DCE-RFC 86.0, where <version-number> is the version number of PAM.
• /usr/share/doc/pam-<version-number>/txts/README.pam_timestamp — Contains information about the pam_timestamp.so PAM module, where <version-number> is the version number of PAM.

Useful PAM Websites

http://www.kernel.org/pub/linux/libs/pam/ — The primary distribution website for the Linux-PAM project, containing information on various PAM modules, a FAQ, and additional PAM documentation.

Note

The documentation in the above website is for the last released upstream version of PAM and might not be 100% accurate for the PAM version included in Fedora.