Los programas que ofrecen al usuario acceso a algún tipo de privilegio necesitan autenticar a los usuarios. Cuando Ud. accede al sistema, introduce su nombre y contraseña, estos son usados por el proceso de registro (login) para autenticar el acceso
verificando que Ud. es quién dice ser. Es posible usar otras formas de autenticación que no sean contraseñas, y es posible almacenar las contraseñas de diferentes maneras.
PAM, del inglés ``Pluggable Authentication Modules, o Módulos de Autenticación Enlazables, permite al administrador del sistema establecer una política de autenticación sin la necesidad de recompilar los programas de autenticación. Mediante PAM, Ud. controla cómo los módulos se conectan a los programas editando un fichero de configuración.
La mayoría de usuarios de Linux Red Hat nunca necesitarán modificar este fichero de configuración. Cuando Ud. utiliza RPM para instalar programas que necesitan hacer autenticación, estos realizarán los cambios necesarios para hacer una autenticación de contraseñas normal. No obstante, Ud. puede personalizar su configuración, en cuyo caso necesitará entender el fichero de configuración.
Módulos
El estándar PAM define cuatro tipos de Módulos. Los módulos auth proporcionan la autenticación en si misma, por un lado solicitando y chequeando la contraseña, y por otro otorgando ``credenciales como miembro de un grupo o ``pases kerberos. Los módulos account comprueban para asegurarse que la autenticación es válida (que la cuenta no haya expirado, que al usuario se le permita registrarse a esa hora del día, etc.). Los módulos password se utilizan para fijar las contraseñas. Los módulos session se utilizan para poner a disposición del usuario su cuenta, una vez que éste se ha autenticado, posiblemente montando su directorio de trabajo o poniendo disponible su cuenta de correo.
Estos módulos pueden apilarse, pudiendo así usar múltiples módulos. Por ejemplo, rlogin normalmente hace uso de al menos dos métodos de autenticación: si tiene éxito la autenticación de ``rhosts, esto es suficiente para permitir la conexión; si fracasa, se realizará la autenticación de contraseñas estándar.
En cualquier momento se podrán añadir nuevos módulos, y entonces las aplicaciones PAM podrán hacer uso de ellos. Por ejemplo, si Ud. tiene un sistema generador de contraseñas de una sola vez, y puede realizar un módulo que lo soporte (con el sistema se incluye documentación sobre la realización de módulos), entonces los programas PAM podrán usar el nuevo módulo y trabajar con el nuevo generador de contraseñas de una sola vez sin tener que recompilar o realizar modificaciones.
Servicios
Cada programa que utilice PAM definirá el nombre de su propio ``servicio. EL programa de registro (login) define el tipo de servicio login, ftpd define el tipo de servicio ftp, etc. En general, el tipo de servicio coincide con el nombre del programa utilizado para acceder al servicio, no (siempre que haya alguna diferencia) el programa utilizado para proporcionar el servicio.
Los ficheros de configuración
El directorio /etc/pam.d se usa para configurar todas las aplicaciones PAM. (En las versiones iniciales de PAM estos se localizaban en /etc/pam.conf; aunque todavía se lee el fichero pam.conf si no se localiza una entrada en /etc/pam.d/, su uso está desaconsejado.) Cada aplicación (realmente, cada servicio) tiene su propio fichero. Un fichero aparecerá como este:
PAM-1.0
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_pwdb.so shadow nullok
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_pwdb.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_pwdb.so shadow
nullok use_authtok
session required /lib/security/pam_pwdb.so
Cualquier línea que comienza con el carácter # es un comentario. Los comentarios en algunas líneas empiezan con el carácter #. Las siguientes tres líneas apilan tres módulos que se usan en la autorización de registro (login). La primera línea nos asegura que si un usuario intenta acceder como superusuario, el terminal (tty) sobre el que accede se encuentre incluido en el fichero /etc/securetty si este existiera. La segunda línea provoca que se solicite al usuario una contraseña y que esta se verifique. La tercera línea comprueba la existencia del fichero /etc/nologin; si es asi, visualiza el contenido del fichero, y si el usuario no es el superusuario, no le permite el acceso al sistema.
Advierta que los tres módulos son verificados, incluso si el primer módulo falla. Esto es debido a una decisión de seguridad
se diseñó así para que el usuario ignore porqué su autenticación se había rechazado, porque conociendo esto, podría permitirle fácilmente evitar la autenticación. Puede cambiar este comportamiento cambiando required por requisite; si algún módulo requisite falla, PAM inmediatamente fallará sin llamar al resto de módulos.
La quinta línea realiza los procesos contables necesarios. Por ejemplo, si se han activado las contraseñas-shadow, el módulo pam_pwdb.so verificará si la cuenta ha expirado, o si el usuario no ha cambiado su contraseña habiendo finalizado el periodo de gracia para cambiarla.
La sexta línea (en la cual tuvimos que introducir un salto de línea) especifica que si el programa de acceso (login) cambia la contraseña del usuario, tendrá que usar el módulo pam_pwdb.so para realizar esto. (Sólo si un módulo auth determina que la contraseña necesita cambiarse
por ejemplo, si una contraseña-shadow ha expirado.)
La última línea especifica que el módulo pam_pwdb.so debe usarse para gestionar la sesión. Actualmente, ese módulo no realiza nada; se puede reemplazar por cualquier módulo necesario.
Tenga en cuenta que es importante el orden de las líneas dentro de cada fichero. Mientras que realmente no importa mucho el orden en el qué se llama a los módulos required, existen disponibles otras banderas de control en las qué esto no es asi. Aunque optional raramente se usa, y nunca por defecto en los sistemas Linux Red Hat, al usar sufficient y requisite, el orden de las líneas se vuelve importante.
Observe la configuración del módulo auth para rlogin:
auth required /lib/security/pam_securetty.so
auth sufficient /lib/security/pam_rhosts_auth.so
auth required /lib/security/pam_pwdb.so shadow nullok
auth required /lib/security/pam_nologin.so
El aspecto es casi como el del fichero login, pero con una línea de más que especifica un módulo extra, y los módulos se especifican en orden diferente.
Primero, pam_securetty.so no permite los accesos del superusuario realizados desde los terminales inseguros. Esto efectivamente, rechaza todos los intentos del superusuario al servicio rlogin. Si desea permitir esto (en cuyo caso, nosotros le recomendamos que, o no este conectado a internet o que tenga su máquina detrás un buén cortafuegos), simplemente elimine esta línea.
Segundo, pam_nologin.so verifica el fichero /etc/nologin, como se especificó anteriormente.
Tercero, si pam_rhosts_auth.so autentifica al usuario, PAM inmediatamente retornará con éxito al servicio rlogin sin que se realice el chequeo de la contraseña. Si
pam_rhosts_auth.so falla al autenticar al usuario, se ignorará la autenticación fallida.
Finalmente (si pam_rhosts_auth.so no autenticó al usuario), el módulo
pam_pwdb.so ejecuta una autenticación de contraseña normal.
Adviertase que si Ud. no quiere que se solicite la contraseña cuando falle el chequeo del terminal seguro, tiene que cambiar la bandera del módulo pam_securetty.so de required a requisite.
Contraseñas-shadow
El soporte de Contraseñas-Shadow se ha cambiado de forma significante para Linux Red Hat 5.0.
El módulo pam_pwdb.so detectará de forma automática el uso de la contraseña-shadow y realizará los ajustes necesarios.
Más información
Esto es sólo una introducción a PAM. Se incluye más información con el sistema en /usr/doc/pam*, que incluye los siguientes documentos.: System Administrators' Guide, Module Writers' Manual, Application Developers' Manual, y el estándar PAM, DCE-RFC 86.0. Además de estos, también existe documentación disponible en la página web de Red Hat, en
http://www.redhat.com/linux-info/pam/##.
