PAM

PAM (Pluggable Authentication Module) no es un modelo de autenticación en sí, sino que se trata de un mecanismo que proporciona una interfaz entre las aplicaciones de usuario y diferentes métodos de autenticación, trantado de esta forma de solucionar uno de los problemas clásicos de la autenticación de usuarios: el hecho de que una vez que se ha definido e implantado cierto mecanismo en un entorno, es difícil cambiarlo. Mediante PAM podemos comunicar a nuestra aplicaciones con los métodos de autenticación que deseemos de una forma transparente, lo que permite integrar las utilidades de un sistema Unix clásico (login, ftp, telnet...) con esquemas diferentes del habitual password: claves de un solo uso, biométricos, tarjetas inteligentes...

PAM viene `de serie' en diferentes sistemas Unix, tanto libres como comerciales (Solaris, FreeBSD, casi todas las distribuciones de Linux...), y el nivel de abstracción que proporciona permite cosas tan interesantes como kerberizar nuestra autenticación (al menos la parte servidora) sin más que cambiar la configuración de PAM, que se encuentra bien en el fichero /etc/pam.conf o bien en diferentes archivos dentro del directorio /etc/pam.d/; en el primero de los dos casos, por ejemplo en Solaris, el fichero de configuración de PAM está formado por líneas de la siguiente forma:
servicio tipo control ruta_módulo argumentos_módulo
El campo `servicio' indica obviamente el nombre del servicio sobre el que se va a aplicar la autenticación (ftp, telnet, dtlogin, passwd...), y el campo `tipo' define el tipo de servicio sobre el que se aplica el módulo; PAM define cuatro posibles valores para este campo ([Her00]): Por su parte, el campo al que hemos etiquetado como `control' marca qué hacer ante el éxito o el fracaso del módulo al que afecten; los módulos PAM son apilables, esto es, podemos combinar un número indeterminado de ellos (del mismo tipo) para un único servicio de forma que si uno de ellos falla la autenticación es incorrecta, si uno de ellos es correcto no nos preocupamos del resto, si algunos son necesarios pero otros no para una correcta autenticación, etc. Se definen cuatro tipos de control: Finalmente, el campo `ruta_modulo' marca el nombre del módulo o la ruta donde está úbicado el fichero, mientras que `argumentos_modulo define los argumentos que se le han de pasar cuando se invoca; este último es el único campo opcional del fichero.

En el caso de que la configuración de PAM se distribuya en diferentes ficheros dentro del directorio /etc/pam.d/ (generalmente implementaciones más modernas, como las de Linux), el nombre de cada fichero marca el servicio al que afecta la autenticación (es decir, encontraremos un archivo llamado `telnet', otro llamado `ftp', etc.), de forma que las líneas de cada fichero únicamente tienen los cuatro últimos campos de los comentados aquí.

Veamos un ejemplo: la autenticación definida para el servicio `login' en un sistema Solaris; el fichero /etc/pam.conf contendrá líneas como las siguientes:
anita:/# grep ^login /etc/pam.conf
login   auth required   /usr/lib/security/$ISA/pam_unix.so.1 
login   auth required   /usr/lib/security/$ISA/pam_dial_auth.so.1 
login   account requisite       /usr/lib/security/$ISA/pam_roles.so.1 
login   account required        /usr/lib/security/$ISA/pam_unix.so.1 
anita:/#
La primera línea indica que cuando un usuario desee autenticarse contra el servicio de `login', ha de ejecutar correctamente el módulo pam_unix, el principal de Solaris, que proporciona funcionalidad para los cuatro tipos de servicio de los que hemos hablado; como en este caso el tipo es `auth', lo que hace el módulo es comparar la clave introducida por el usuario con la que existe en el archivo de contraseñas de la máquina, autenticándolo si coinciden. Evidentemente, el control es de tipo `required', lo que viene a decir que el password tecleado ha de ser el correcto para poder autenticarse contra el sistema; algo parecido sucede con la segunda línea, que invoca al módulo pam_dial_auth, encargado de validar la línea de conexión y las claves de dialup en Solaris, si los archivos /etc/dialups y /etc/d_passwd existen. Si cualquiera de los módulos devolviera un código de ejecución incorrecta, el acceso al servicio de login - el acceso a la máquina - se denegaría.

Las dos líneas siguientes se utilizan para la gestión de las claves de usuario, también para el control de acceso al servicio `login'; el módulo pam_roles comprueba que el usuario que ejecuta el proceso está autorizado a asumir el rol del usuario que quiere autenticarse, mientras que pam_unix, del que ya hemos hablado, lo que hace ahora que el tipo de servicio es `account' es simplemente verificar que el password del usuario no ha caducado. El tipo de control en el primer caso es `requisite', lo que implica que si el módulo falla directamente se niega el acceso y no se ejecuta el módulo pam_unix; si el primero no falla, sí que se ejecuta este último, y su resultado ha de ser correcto para permitir el acceso (algo por otra parte evidente).

La arquitectura PAM ha venido a solucionar diferentes problemas históricos de la autenticación de usuarios en entornos Unix - especialmente en entornos complejos, como sistemas distribuidos o reinos Kerberos; proporciona una independencia entre los servicios del sistema y los mecanismos de autenticación utilizados, beneficiando tanto al usuario como a los administradores Unix. Desde 1995, año en que se adoptó la solución propuesta por Sun Microsystems hasta la actualidad, cada vez más plataformas integran PAM por defecto, con lo que se ha convertido en el estándar de facto en la autenticación dentro de entornos Unix.
© 2002 Antonio Villalón Huerta