14.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 path> <module arguments> |
En las siguientes secciones se explican cada uno de estos elementos.
14.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:
auth — Estos módulos autentifican a los usuarios tal vez pidiendo y controlando una contraseña. Los módulos con esta interfaz también pueden establecer credenciales, tales como membrecías de grupo o tickets Kerberos.
account — Estos módulos controlan que la autenticación sea permitida (que la cuenta no haya caducado, que el usuario tenga permiso de iniciar sesiones a esa hora del día, etc.).
password — Estos módulos se usan para establecer y verificar contraseñas.
session — Estos módulos configuran y administran sesiones de usuarios. Los módulos con esta interfaz también pueden realizar tareas adicionales que son necesitadas para permitir acceso, como el montaje de directorios principales de usuarios y hacer el buzón de correo disponible.
 | Nota |
|---|---|
Un módulo individual puede proporcionar alguno o todas las interfaces de módules mencionadas anteriormente. Por ejemplo, pam_unix.so tiene componentes que direccionan las cuatro interfaces. |
En un archivo de configuración PAM, la interfaz del módulo es el primer aspecto a definir. Por ejemplo, una línea típica de una configuración sería:
auth required /lib/security/pam_unix.so |
Esto provoca que PAM observe el componente pam_unix.so del módulo auth.
14.3.1.1. Apilar módulos
Las directivas de interfaces de módulos pueden ser apiladas o colocar uno sobre otro para que se puedan usar módulos múltiples para un mismo propósito. 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 /lib/security/pam_nologin.so auth required /lib/security/pam_securetty.so auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_rhosts_auth.so auth required /lib/security/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 y que se pueda cargar cualquier variable de entorno. Entonces se lleva a cabo una autenticación rhosts exitosa antes que se permita la conexión. Si falla la autenticación rhosts entonces se lleva a cabo una autenticación de contraseña estándar.
14.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:
required — El resultado del módulo debe ser exitoso para que la autenticación continue. Si un módulo required falla, el usuario no es notificado hasta que los resultados en todos los módulos referenciando esa interfaz sean completados.
requisite — El resultado del módulo debe ser exitóso para que la autenticación continue. Sin embargo, si el resultado de un módulo requisite falla, el usuario es notificado inmediatamente con un mensaje reflejando el primer módulo required o requisite fracasado.
sufficient — El resultado del módulo es ignorado si falla. Pero si el resultado del módulo con el indicador sufficient es exitoso and ningún módulo con indicador required ha fallado, entonces no se requiere ningún otro resultado y el usuario es autenticado para el servicio.
optional — Se ignora el resultado del módulo si falla. Si el resultado del módulo es exitoso, no juega ningún papel en el éxito o fracaso general para el módulo. Un módulo con una bandera optional es necesario para la autenticación exitosa cuando no hay otros módulos referenciando la interfaz. En este caso, un módulo optional determina la autenticación PAM para esa interfaz.
 | Importante |
|---|---|
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. |
Una sintaxis más nueva de indicadores de control que permite un control más preciso está disponible para PAM. Por favor revises 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).
14.3.3. Rutas de módulos
Las rutas de los módulos le indican a PAM dónde encontrar el módulo conectable que hay que usar con el tipo de interfaz de módulo especificada. Generalmente, se proporciona como una ruta completa de módulo, como /lib/security/pam_stack.so. Sin embargo, si no se proporciona la ruta entera, entonces se asume que el módulo está en el directorio /lib/security/, la dirección por defecto de los módulos PAM.
14.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 /lib/security/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.
Los argumentos inválidos se ignoran 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.