16.3. Formato del archivo de configuraci�n PAM
Cada archivo de configuraci�n PAM contiene un grupo de directivas formateadas como sigue:
<module interface> <control flag> <module name> <module arguments> |
En las siguientes secciones se explican cada uno de estos elementos.
16.3.1. Interfaz de m�dulo
Existen cuatro tipos de m�dulos PAM usados para controlar el acceso a los servicios. Estos tipos establecen una correlaci�n entre los diferentes aspectos del proceso de autorizaci�n:
auth — Esta interfaz de m�dulo autentifican el uso.Por ejemplo, solicita y verifica la validez de una contrase�a. Los m�dulos con esta interfaz tambi�n pueden establecer credenciales, tales como membrec�as de grupo o tickets Kerberos.
account — Esta interfaz de m�dulo verifica que sea permitido el acceso. Por ejemplo, puede verificar que la cuenta no haya caducado o que el usuario tenga permiso de iniciar sesiones a una hora del d�a particular.
password — Este m�dulo se usa para establecer y verificar contrase�as.
session — Esta interfaz de m�dulo configura y administra las sesiones de usuarios. Los m�dulos con esta interfaz tambi�n pueden realizar tareas adicionales que son requeridas para permitir acceso, como el montaje de directorios principales de usuarios y hacer el buz�n de correo del usuario disponible.
 | Nota |
|---|
| | Un m�dulo individual puede proporcionar alguna o todas las interfaces de m�dulos mencionadas anteriormente. Por ejemplo, pam_unix.so proporciona todas las cuatro interfaces. |
En un archivo de configuraci�n PAM, la interfaz del m�dulo es el primer campo a definir. Por ejemplo, una l�nea t�pica de una configuraci�n ser�a:
auth required pam_unix.so |
Esto provoca que PAM observe el componente pam_unix.so del m�dulo auth.
16.3.1.1. Apilar interfaces de m�dulos
Las directivas de interfaces de m�dulos pueden ser apiladas o colocadas una sobre otra para que se puedan usar m�ltiples m�dulos para un mismo prop�sito. Por esta raz�n, el orden de una pila de m�dulos es muy importante en el procedimiento de autenticaci�n.
El hecho de apilarlos hace que sea m�s f�cil para que el administrador exija diversas condiciones antes de permitir la autentificaci�n del usuario. Por ejemplo, rlogin normalmente usa cinco m�dulos auth, como se puede ver en el archivo de configuraci�n de PAM:
auth required pam_nologin.so
auth required pam_securetty.so
auth required pam_env.so
auth sufficient pam_rhosts_auth.so
auth required pam_stack.so service=system-auth |
Antes de que a alguien se le permita llevar a cabo el rlogin, PAM verifica que el archivo /etc/nologin no exista, que no est� intentando iniciar una sesi�n en modo remoto como root sobre una conexi�n de red y que se pueda cargar cualquier variable de entorno. Entonces si se lleva a cabo una autenticaci�n rhosts exitosa, se permita la conexi�n. Si falla la autenticaci�n rhosts entonces se lleva a cabo una autenticaci�n de contrase�a est�ndar.
16.3.2. Indicadores de control
Todos los m�dulos PAM generan un resultado de �xito o fracaso cuando se les llama. 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 al objetivo final del proceso de autenticaci�n para el servicio.
Hay cuatro indicadores de control definidos:
required — El resultado del m�dulo debe ser exitoso para que la autenticaci�n continue. Si un m�dulo required falla, el usuario no es notificado hasta que los resultados en todos los m�dulos referenciando esa interfaz sean completados.
requisite — El resultado del m�dulo debe ser exit�so para que la autenticaci�n continue. Sin embargo, si el resultado de un m�dulo requisite falla, el usuario es notificado inmediatamente con un mensaje reflejando el primer m�dulo required o requisite fracasado.
sufficient — El resultado del m�dulo es ignorado si falla. Pero si el resultado del m�dulo con el indicador sufficient es exitoso y ning�n m�dulo con indicador required ha fallado, entonces no se requiere ning�n otro resultado y el usuario es autenticado para el servicio.
optional — Se ignora el resultado del m�dulo.Un m�dulo con una bandera optional s�lo es necesario para la autenticaci�n exitosa cuando no hay otros m�dulos referenciando la interfaz.
 | Importante |
|---|
| | El orden en el cual se llaman los m�dulos required no es cr�tico. Las banderas o indicadores de control sufficient y requisite provocan que el orden se vuelva importante. |
Ahora est� disponible para PAM una sintaxis m�s nueva de indicadores de control que permiten un control m�s preciso. Por favor revise los documentos de PAM localizados en el directorio /usr/share/doc/pam-<version-number>/ para informaci�n sobre esta nueva sintaxis (donde <version-number> es el n�mero de versi�n de PAM).
16.3.3. Nombre del m�dulo
El nombre del m�dulo le proporciona a PAM el nombre del m�dulo que contiene la interfaz del m�dulo especificada. Bajo las versiones anteriores de Red Hat Enterprise Linux, se proporcionaba la ruta completa al m�dulo dentro del archivo de configuraci�n PAM, tal como /lib/security/pam_stack.so. Sin embargo, desde el advenimiento de sistemas multilib, que almacenan m�dulos PAM de 64-bits dentro del directorio /lib64/security/, el nombre del directorio es omitido debido a que las aplicaciones son enlazadas a la versi�n apropiada de libpam, que puede ubicar la versi�n correcta del m�dulo.
16.3.4. Argumentos de m�dulo
PAM utiliza argumentos para transmitir informaci�n a un m�dulo conectable durante la autenticaci�n para algunos m�dulos.
Por ejemplo, el m�dulo pam_userdb.so usa secretos almacenados en una base de datos Berkeley DB file para autenticar a los usuarios. La base de datos Berkeley es una base de datos open source incorporado en muchas aplicaciones. El m�dulo toma un argumento db para que la base de datos Berkeley conozca que base de datos usar para el servicio solicitado.
Una l�nea t�pica pam_userdb.so dentro de un archivo PAM es similar a:
auth required pam_userdb.so db=<path-to-file> |
En el ejemplo anterior, sustituya <path-to-file> con la ruta completa al archivo de base de datos Berkeley.
Se ignoran los argumentos inv�lidos y no afectan en ning�n modo el �xito o fracaso del m�dulo PAM. Sin embargo, la mayor�a de los m�dulos reportar�n un error al archivo /var/log/messages.
