Autenticación PAM en Linux, Elevando la seguridad.

PAM (Pluggable Authentication Modules) es un mecanismo flexible para la autenticación de usuarios centralizado. Permite modelar políticas de seguridad personalizada dependiendo el servicio para distintos usuarios.

Red hat lo implementa por defecto en su sistema. Permite el desarrollo de programas independientes del mecanismo de autenticación que utilicemos, es un refuerzo de estos como por ejemplo del clásico /etc/passwd que cifra la contraseña en el /etc/shadow

Grupos de gestión.

Se puede dividir la gestión en grupos independientes.

account: tareas no relacionadas con la autenticación. Como permitir o denegar el acceso en función de un horario, recursos o ubicación geográfica.

authentication: tareas encaminadas a comprobar el usuario. Es la tarea más genérica y la que más identifica a PAM

password: Mantiene actualizado el elemento autenticador de cada usuario, como por ejemplo su contraseña. Se comprueba la fortaleza y que cumpla las políticas definidas, longitud, tipo de caracteres, repeticiones, descartar palabras de diccionario.

sesion: Engloba tareas que se deben llevar a cabo antes del inicio del servicio y cuando finaliza.

1 – Ficheros de configuración

El fichero de configuración por defecto es el /etc/pam.conf pero también podemos configurar cada servicio (lo más aconsejado) de forma individual en el /etc/pam.d, como es habitual si modificamos el .conf, haremos backup con fecha del mismo por si nos surgen problemas. Siempre la configuración modular es más recomendable.

La diferencia más notable es que en el pam.conf hay que indicar el servicio, mientras que en el pam.d el fichero se llama con el mismo nombre del servicio que implementa, siendo más intuitivo y más fácil de administrar.

Este es el listado de un fichero de ejemplo

root@nexolinux ~ # ls /etc/pam.d/

atd gdmsetup pm-suspend sshd system-config-network
authconfig gnome-screensaver pm-suspend-hybrid su system-config-network-cmd
authconfig-gtk gnome-system-log poweroff sudo system-config-printer
authconfig-tui gssftp ppp sudo-i system-config-rootpassword
chfn halt pup su-l system-config-securitylevel
chsh kbdrate reboot system-auth system-config-selinux
config-util kshell remote system-auth-ac system-config-services
cpufreq-selector ksu rhn_register system-cdinstall-helper system-config-soundcard
crond login run_init system-config-authentication system-config-time
cups neat runuser system-config-date system-config-users
cvs newrole runuser-l system-config-display system-install-packages
dateconfig other sabayon system-config-kdump vmtoolsd
eject passwd serviceconf system-config-keyboard xserver
ekshell pirut setup system-config-language
gdm pm-hibernate smtp system-config-lvm
gdm-autologin pm-powersave smtp.sendmail system-config-netboot

2- Reglas

Los ficheros de configuracion tienen una serie de reglas, una por línea. Se ignoran las que comienzan por el clásico «#» y pueden ser varias a la vez con «\»

Siguen esta nomenclatura:

servicio tipo control ruta [argumentos]

Un detalle, los campos rutas y argumentos respetan mayúsculas, el resto no.
Este es un ejemplo del fichero sudo:

root@nexolinux ~ # cat /etc/pam.d/sudo
#%PAM-1.0
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so

2.1 Servicio

Nombre de la aplicación o servicio, sólo se usa en el fichero pam.conf

2.2 Tipo

Pam se divide en las cuatro tareas vistas anteriormente, tipo define en cual definimos la regla. auth,account, session o password.

2-3 Control

Indica a PAM que hacer en caso de éxito/fallo, se ejecutan en serio todos los del mismo tipo y ese orden (lee las reglas de arriba a a abajo, se denomina «pila») hay que tenerlo muy en cuenta a la hora de configurarlo Se pueden usar dos sintaxis:

Una sóla palabra o una más compleja que implica valor-acción

La sencilla la dividimos en cuatro valores:

2.3.1 required – Indica que es necesario que el módulo tenga éxito para que la pila lo tenga. Si hay fallo no lo veremos hasta que se procese el resto

2.3.2 requisite – Es igual que el anterior pero en caso de fallo nos devuelve a la aplicación.

2.3.3 sufficient – si en los anteriores no se ha producido fallo, da el visto bueno. A partir de este punto ignora los siguientes required posibles.

2.3.4 optional – PAM ignora los módulos marcados por este indicador, salvo si no se llega a ningún valor en concreto de éxito o fracaso.

La otra sintaxis es más complicada [valor=accion]

2.3.4.1 Valor (algunos ejemplos):

Se escriben sin el prefijo PAM_ y en minúscula.

PAM_AUTH_ERR – error de autenticación

PAM_MAXTRIES – alcanzado número máximo de intentos

PAM_USER_UNKNOW – nombre de usuario desconocido

PAM_ACCT_EXPIRED – cuenta de usuario expirada.

PAM_PERM_DENIED – permiso denegado.

2.3.4.2  Accion puede ser un número «n» o lo siguiente:

– ignore, si el valor es N se ignora.

– bad, si es el primer módulo en fallar, el valor que devuelva la pila será este módulo.

– die, equivalente al anterior, pero devuelve el control a la aplicación de inmediato.

– ok, si hasta este momento tiene éxito la lectura de la pila. El código será sobreescrito por este módulo.

– done, funciona como el anterior, pero llegado a este punto devuelve el control a la aplicación.

– reset, olvida el estado de la pila y sigue con el siguiente módulo.

Respecto al número «n» indica que deben saltarse los siguientes «n» módulos.

Por último esta es la tabla de equivalencias entre la sintaxis de control sencillo y control complejo:

required equivale a [success=ok newauthok_reqd=ok ignore=ignore default=bad].
requisite equivale a [success=ok newauthok_reqd=ok ignore=ignore default=die].
sufficient equivale a [success=done new_authok_reqd=done default=ignore].
optional equivale a [success=ok new_authtok_reqd=ok default=ignore].

2.4 Ruta

Contiene la ruta del módulo a utilizar, una ruta absoluta, o relativa a /lib/security

2.5 Argumentos.

Argumentos que pueden ser pasados al módulo. Específicos para cada módulo y deberían estar documentados.