Ficheros de configuración PAM
El directorio /etc/pam.d contiene los ficheros de configuración de PAM. En versiones antiguas de PAM se utilizaba /etc/pam.conf. El fichero pam.conf todavía se lee si no se encuentran entradas /etc/pam.d/, pero se desaprueba su uso.
Cada aplicación (o servicio, como se conocen comúnmente las aplicaciones proyectadas para ser usadas por muchos usuarios) tiene su propio fichero. Cada fichero tiene cinco elementos diferentes: el nombre de servicio , el tipo de módulo, el indicador de control , la ruta de módulo y los argumentos.
Nombres de servicio de PAM
El nombre de servicio de todas las aplicaciones habilitadas para PAM es el nombre de su fichero de configuración en /etc/pam.d. Cada programa que usa PAM define su propio nombre de servicio.
Por ejemplo, el programa login define el nombre de servicio login, ftpd define el nombre de servicio ftp, etc.
Generalmente, el nombre de servicio es el nombre del programa usado para obtener acceso al servicio, no del programa usado para proporcionar el servicio.
Los módulos de PAM
PAM contiene cuatro tipos diferentes de módulos para controlar el acceso a determinados servicios:
Los módulos auth proporcionan la autentificación en sí (tal vez pidiendo y controlando una contraseña) y establecen las credenciales, como la afiliación de grupo o los billetes de Kerberos.
Los módulos account controlan que la autentificación sea permitida (que la cuenta no haya caducado, que el usuario tenga permiso de iniciar sesiones a esa hora del día, etc.).
Los módulos password se usan para establecer contraseñas.
Los módulos session se usan después de que un usuario ha sido autentificado. Los módulos session permiten que alguien use su cuenta (para armar el directorio de inicio del usuario o poner a disposición su buzón electrónico, por ejemplo).
Estos módulos se pueden apilar, o colocar uno sobre otro para que se puedan usar los módulos múltiples. El orden de una pila de módulos es muy importante en el procedimiento de autentificación, porque facilita mucho al trabajo del un administrador el requerir que existan varias condiciones antes de permitir que se lleve a cabo la autentificación del usuario.
Por ejemplo, rlogin normalmente usa por lo menos cuatro métodos de autentificación apilados, como se puede ver en su fichero de configuración 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 account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session 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 fichero /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 autentificación rhosts exitosa antes que se permita la conexión. Si falla la autentificación rhosts, entonces se lleva a cabo una autentificación de contraseña estándar.
Se pueden añadir módulos PAM nuevos en cualquier momento y después se pueden crear aplicaciones que se puedan usar con los módulos de PAM. Si por ejemplo usted crea un método de creación de contraseñas para usarse una sola vez y escribe un módulo PAM que lo soporte, los programas conscientes de PAM pueden usar el módulo nuevo y el método para contraseñas inmediatamente sin tener que ser recompilados o modificados. Como podrá imaginar, esto es muy positivo, porque le permite combinar y emparejar, además de probar, los métodos de autentificación muy rápidamente con programas diferentes sin tener que recompilar los programas.
La documentación sobre la escritura de módulos contenida en el sistema se encuentra en /usr/share/doc/pam—<version-number>.
Los indicadores de control PAM
Todos los módulos PAM generan un resultado de éxito o fracaso cuando se les hace un control. 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 a los módulos que lo siguen.
Una vez más, considere el fichero de configuración PAM rlogin:
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 account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth |
Antes de que se especifique el tipo de módulo, los indicadores de control deciden la importancia con la que debería ser considerado ese determinado tipo de módulo en cuanto al propósito general de permitirle a ese usuario el acceso a ese programa.
El estándar PAM define cuatro tipos de indicadores de control:
Los módulos required indicados deben ser controlados con éxito para que se permita la autentificación. Si fracasa el control de un módulo required, el usuario no recibirá un aviso hasta que no hayan sido controlados los demás módulos del mismo tipo.
Los módulos requisite indicados también deben ser controlados con éxito para que la autentificación sea exitosa. Sin embargo, si fracasa un control de módulo requisite, el usuario recibe un aviso inmediatamente con un mensaje que refleja el primer módulo required o requisite fracasado.
Si fracasan los controles a módulos sufficient indicados, se ignoran. Pero si un módulo sufficient indicado pasa el control con éxito y ningún módulo required indicado antes de ese ha fracasado, entonces ningún otro módulo de este tipo se controlará y este tipo de módulo será considerado como controlado exitosamente por entero.
los módulos optional indicados no son esenciales para el éxito o fracaso general de la autentificación para ese tipo de módulo. Desempeñan un papel sólo cuando ningún otro módulo de ese tipo ha tenido éxito o ha fallado. En este caso el éxito o fracaso de un módulo optional indicado determina la autentificación PAM general para ese tipo de módulo.
Ya está a disposición para PAM una sintaxis de indicador de control más nueva que permite más control. Consulte la documentación de PAM ubicada en /usr/share/doc/pam—<version-number> para obtener más información sobre esta sintaxis nueva.
Rutas de módulos PAM
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 módulo especificado. Generalmente, se proporciona como una ruta entera de módulo, como /lib/security/pam_stack.so. Sin embargo, si no se proporciona la ruta entera (o sea que la ruta no inicia con /), entonces se supone que el módulo indicado está en /lib/security, la ubicación por defecto para los módulos PAM.
Argumentos PAM
PAM utiliza argumentos para transmitir información a un módulo conectable durante la autentificación para ese determinado tipo de módulo. Estos argumentos permiten que los ficheros de configuración PAM para determinados programas utilicen un módulo PAM común pero en maneras diferentes.
Por ejemplo, el módulo pam_userdb.so utiliza los secretos almacenados en un fichero Berkeley DB para autentificar al usuario. (Berkeley DB es un sistema de base de datos de open source proyectado para ser incrustado en muchas aplicaciones para rastrear determinados tipos de información.) El módulo toma un argumento db, especificando el nombre de fichero Berkeley DB que hay que usar, el cual puede variar según el servicio.
La línea pam_userdb.so en un fichero de configuración PAM sería más o menos así:
auth required /lib/security/pam_userdb.so db=path/to/file |
Los argumentos inválidos se ignoran y no afectan en ningún modo el éxito o fracaso del módulo PAM. Cuando pasa un argumento inválido, el error normalmente se escribe en /var/log/messages. Sin embargo, como el método de informe está controlado por el módulo PAM, depende del módulo registrar el error correctamente.
Muestras de ficheros de configuración PAM
Un fichero de muestra de configuración de la aplicación PAM tiene este aspecto:
#%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_unix.so shadow nullok auth required /lib/security/pam_nologin.so account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_unix.so shadow nullok use_authtok session required /lib/security/pam_unix.so |
La primera línea es un comentario (cualquier línea que inicie con el carácter # es un comentario). Las líneas dos, tres y cuatro apilan tres módulos a usar para autentificaciones de inicio de sesión.
auth required /lib/security/pam_securetty.so |
La segunda línea se asegura de si el usuario está intentando el registro como root, el tty en el que se están registrando está listado en el fichero /etc/securetty, si éste existe.
auth required /lib/security/pam_unix.so shadow nullok |
La línea tres causa que se le pida la contraseña al usuario y que la contraseña sea controlada.
auth required /lib/security/pam_nologin.so |
La línea cuatro controla si existe el fichero /etc/nologin. Si /etc/nologin existe y el usuario no es de root, la autentificación falla.
Note que se controlan los tres módulos auth, no importa si falla el primer módulo auth. Esta estrategia no permite que el usuario se dé cuenta de por qué no se ha permitido su autentificación. Si se sabe por qué falla una autentificación tal vez al próximo intento será más fácil pase la autentificación. Este comportamiento se puede modificar cambiando required a requisite. Si fracasa cualquier módulo requisite PAM falla inmediatamente sin llamar ningún otro módulo.
account required /lib/security/pam_unix.so |
La quinta línea hace que se efectúe cualquier verificación de cuenta que fuese necesaria. Si por ejemplo se han habilitado contraseñas shadow, el módulo pam_unix.so controlará si la cuenta ha caducado o si el usuario no ha cambiado su contraseña dentro del plazo permitido.
password required /lib/security/pam_cracklib.so |
La quinta línea prueba la contraseña recién cambiada controlando si la contraseña puede ser fácilmente descubierta por un programa de descubrimiento de contraseñas basado en diccionarios.
password required /lib/security/pam_unix.so shadow nullok use_authtok |
La séptima línea especifica que si el programa login cambia la contraseña del usuario, debería utilizar el módulo pam_unix.so para hacerlo. (Esto sucederá sólo si un módulo auth ha determinado que debe cambiarse la contraseña — en el caso que haya caducado una contraseña shadow, por ejemplo.)
session required /lib/security/pam_unix.so |
La octava y final línea especifica que el módulo pam_unix.so debería usarse para administrar la sesión. Actualmente ese módulo no hace nada; podría ser reemplazado por cualquier módulo necesario o suplementado por medio de una pila.
Note que el orden en que están las líneas dentro de cada fichero tiene importancia. Mientras el orden en que los módulos required van llamados no tiene mucha importancia, hay otros indicadores de control a disposición. Mientras optional se utiliza raramente, sufficient y requisite hacen que el orden tenga importancia.
Como siguiente ejemplo repasaremos la configuración auth para el rlogin:
#%PAM-1.0 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 |
Primero, pam_nologin.so controla para ver si /etc/nologin existe. Si existe, nadie puede iniciar una sesión excepto a nivel de root.
auth required /lib/security/pam_securetty.so |
Segundo, pam_securetty.so no permite que los inicios de sesión a nivel de root ocurran en terminales inseguras. Esto rechaza eficazmente cualquier intento de rlogin a nivel de root. Si desea permitirles (en tal caso debería encontrarse detrás de un buen cortafuego o no estar conectado a Internet) hacer esto, consulte la la sección de nombre El uso de rlogin, rsh, y rexec con PAM.
auth required /lib/security/pam_env.so |
Tercero, el módulo pam_env.so carga las variables de entorno especificadas en /etc/security/pam_env.conf.
auth sufficient /lib/security/pam_rhosts_auth.so |
Cuarto, se pam_rhosts_auth.so autentifica al usuario por medio de .rhosts en el directorio de inicio del usuario, PAM inmediatamente autentifica el rlogin sin proseguir con una autentificación de contraseña normal con pam_stack.so. Si pam_rhosts_auth.so no logra autenticar al usuario, se ignora esa autentificación fracasada.
auth required /lib/security/pam_stack.so service=system-auth |
Quinto, si pam_rhosts_auth.so no ha logrado autentificar al usuario, el módulo pam_stack.so ejecuta una autentificación de contraseña normal y se pasa al service=system-auth argumento.
 | Nota |
|---|---|
Si no desea que se pida la contraseña cuando el control securetty fracasa y determina que el usuario está intentando iniciar una sesión a nivel de root en modo remoto, puede cambiar el módulo pam_securetty.so de required a requisite. Como alternativa, si desea permitir inicios de sesión a nivel de root remotos (que no es muy buena idea), puede convertir esta línea en comentario. |