Red Hat Enterprise Linux 3: Manual de referencia | ||
---|---|---|
Anterior | Capítulo 15. Pluggable Authentication Modules (PAM) | Siguiente |
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.
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 — Esta interfaz de módulo autentifican el uso.Por ejemplo, solicita y verifica la validez de una contraseña. Los módulos con esta interfaz también pueden establecer credenciales, tales como membrecías de grupo o tickets Kerberos.
account — Esta interfaz de módulo verifica que sea permitido el acceso. Por ejemplo, puede verificar que la cuenta no haya caducado o que el usuario tenga permiso de iniciar sesiones a una hora del día particular.
password — Este módulo se usa para establecer y verificar contraseñas.
session — Esta interfaz de módulo configura y administra las sesiones de usuarios. Los módulos con esta interfaz también pueden realizar tareas adicionales que son requeridas para permitir acceso, como el montaje de directorios principales de usuarios y hacer el buzón de correo del usuario disponible.
![]() | Nota |
---|---|
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 aspecto 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.
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.
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 y 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.Un módulo con una bandera optional sólo es necesario para la autenticación exitosa cuando no hay otros módulos referenciando la 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).
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.
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.
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.