16.3. Formato del archivo de configuración PAM

Cada archivo de configuración PAM contiene un grupo de directivas formateadas como sigue:

<module interface>  <control flag>   <module name>   <module arguments>

En las siguientes secciones se explican cada uno de estos elementos.

16.3.1. Interfaz de módulo

Existen cuatro tipos de módulos PAM usados para controlar el acceso a los servicios. Estos tipos establecen una correlación entre los diferentes aspectos del proceso de autorización:

NotaNota
 

Un módulo individual puede proporcionar alguna o todas las interfaces de módulos mencionadas anteriormente. Por ejemplo, pam_unix.so proporciona todas las cuatro interfaces.

En un archivo de configuración PAM, la interfaz del módulo es el primer campo a definir. Por ejemplo, una línea típica de una configuración sería:

auth      required  pam_unix.so

Esto provoca que PAM observe el componente pam_unix.so del módulo auth.

16.3.1.1. Apilar interfaces de módulos

Las directivas de interfaces de módulos pueden ser apiladas o colocadas una sobre otra para que se puedan usar múltiples módulos para un mismo propósito. Por esta razón, el orden de una pila de módulos es muy importante en el procedimiento de autenticación.

El hecho de apilarlos hace que sea más fácil para que el administrador exija diversas condiciones antes de permitir la autentificación del usuario. Por ejemplo, rlogin normalmente usa cinco módulos auth, como se puede ver en el archivo de configuración de PAM:

auth       required     pam_nologin.so
auth       required     pam_securetty.so
auth       required     pam_env.so
auth       sufficient   pam_rhosts_auth.so
auth       required     pam_stack.so service=system-auth

Antes de que a alguien se le permita llevar a cabo el rlogin, PAM verifica que el archivo /etc/nologin no exista, que no esté intentando iniciar una sesión en modo remoto como root sobre una conexión de red y que se pueda cargar cualquier variable de entorno. Entonces si se lleva a cabo una autenticación rhosts exitosa, se permita la conexión. Si falla la autenticación rhosts entonces se lleva a cabo una autenticación de contraseña estándar.

16.3.2. Indicadores de control

Todos los módulos PAM generan un resultado de éxito o fracaso cuando se les llama. Los indicadores de control le dicen a PAM qué hacer con el resultado. Como los módulos pueden apilarse en un determinado orden, los indicadores de control le dan la posibilidad de fijar la importancia de un módulo con respecto al objetivo final del proceso de autenticación para el servicio.

Hay cuatro indicadores de control definidos:

ImportanteImportante
 

El orden en el cual se llaman los módulos required no es crítico. Las banderas o indicadores de control sufficient y requisite provocan que el orden se vuelva importante.

Ahora está disponible para PAM una sintaxis más nueva de indicadores de control que permiten un control más preciso. Por favor revise los documentos de PAM localizados en el directorio /usr/share/doc/pam-<version-number>/ para información sobre esta nueva sintaxis (donde <version-number> es el número de versión de PAM).

16.3.3. Nombre del módulo

El nombre del módulo le proporciona a PAM el nombre del módulo que contiene la interfaz del módulo especificada. Bajo las versiones anteriores de Red Hat Enterprise Linux, se proporcionaba la ruta completa al módulo dentro del archivo de configuración PAM, tal como /lib/security/pam_stack.so. Sin embargo, desde el advenimiento de sistemas multilib, que almacenan módulos PAM de 64-bits dentro del directorio /lib64/security/, el nombre del directorio es omitido debido a que las aplicaciones son enlazadas a la versión apropiada de libpam, que puede ubicar la versión correcta del módulo.

16.3.4. Argumentos de módulo

PAM utiliza argumentos para transmitir información a un módulo conectable durante la autenticación para algunos módulos.

Por ejemplo, el módulo pam_userdb.so usa secretos almacenados en una base de datos Berkeley DB file para autenticar a los usuarios. La base de datos Berkeley es una base de datos open source incorporado en muchas aplicaciones. El módulo toma un argumento db para que la base de datos Berkeley conozca que base de datos usar para el servicio solicitado.

Una línea típica pam_userdb.so dentro de un archivo PAM es similar a:

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

En el ejemplo anterior, sustituya <path-to-file> con la ruta completa al archivo de base de datos Berkeley.

Se ignoran los argumentos inválidos y no afectan en ningún modo el éxito o fracaso del módulo PAM. Sin embargo, la mayoría de los módulos reportarán un error al archivo /var/log/messages.