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]):
- account
Determina si el usuario está autorizado a acceder al servicio indicado, por ejemplo si su clave ha caducado, si el acceso se produce desde una línea determinada o si se supera el número máximo de conexiones simultáneas.
- auth
Determina si el usuario es autenticado correctamente, por ejemplo mediante una clave clásica de Unix o mediante un método biométrico.
- password
Proporciona mecanismos para que el usuario actualice su elemento de autenticación, por ejemplo para cambiar su contraseña de acceso al sistema.
- session
Define procesos a ejecutar antes o después de autenticar al usuario, como registrar el evento o activar un mecanismo de monitorización concreto.
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:
- required
El resultado del módulo ha de ser exitoso para que se proporcione acceso al servicio; si falla, el resto de módulos de la pila se ejecutan, pero sin importar su resultado el acceso será denegado.
- requisite
De nuevo, el resultado del módulo ha de ser exitoso para que se proporcione acceso al servicio; en caso contrario, no se ejecutan más módulos y el acceso se deniega inmediatamente.
- sufficient
Si la ejecución el módulo correspondiente tiene éxito el acceso se permite inmediatamente (sin ejecutar el resto de módulos para el mismo servicio) siempre y cuando no haya fallado antes un módulo cuyo tipo de control sea `required'; si la ejecución es incorrecta, no se implica necesariamente una negación de acceso.
- optional
El resultado de su ejecución no es crítico para determinar el acceso al servicio requerido: si falla, pero otro módulo del mismo tipo para el servicio es exitoso, se permite el acceso. Sólo es significativo si se trata del único módulo de su tipo para un cierto servicio, en cuyo caso el acceso al servicio se permite o deniega en función de si la ejecución del módulo tiene éxito.
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.
