En un artículo anterior, describí el flujo de una aplicación que llama a las bibliotecas PAM para la autenticación a un nivel muy alto. En este artículo, revisaremos los archivos de configuración para un sudo local. comando.
Al usar sudo , cambiamos de usuario y hacemos algo. Este cambio de privilegio requiere la verificación de que somos quienes decimos que somos y se nos permite realizar la acción dada. El /etc/sudoers El archivo controla quién puede hacer qué, pero el proceso aún llama a PAM para cualquier verificación de autenticación. Como parte de estas llamadas, el proceso se identifica a sí mismo y luego libpam busca un archivo de configuración coincidente en /etc/pam.d directorio.
$ cat /etc/pam.d/sudo
#%PAM-1.0
#Type ReturnCode Modules Options
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
session include system-auth
Como muchos otros directorios *.d, la administración de paquetes puede agregar o eliminar un archivo de este directorio. El sudo RPM agrega el /etc/pam.d/sudo archivo.
$ rpm -qf /etc/pam.d/sudo
sudo-1.9.0-0.1.b4.fc31.x86_64
Una versión anterior puede tener una variedad de entradas, pero este paquete proporcionado por la distribución incluye un archivo de configuración que tiene varios incluir declaraciones al común /etc/pam.d/system-auth archivo proporcionado por pam paquete.
Campos del archivo de configuración
El primer campo de este archivo identifica un Tipo de llamada realizada a PAM. Las líneas del mismo tipo se agrupan. Hay cuatro tipos:autenticación, cuenta, contraseña y sesión. Mira a man pam para obtener una descripción de cada tipo.
El segundo campo se conoce como ReturnCode . Este campo le permite a PAM saber cómo manejar los resultados de la prueba del módulo. Los códigos de retorno indican si una prueba es obligatoria u opcional. Los códigos también pueden usarse para indicar que la línea no es una prueba de módulo con opciones, sino el nombre de otro archivo de configuración con comprobaciones adicionales. Una descripción completa de los códigos de retorno se encuentra en man pam.conf , y los más comunes se analizan más adelante en este artículo.
El resto de la línea contiene el nombre del módulo y las opciones para ese módulo. El nombre del módulo debe coincidir con un módulo disponible en /etc/lib64/security directorio. Las opciones pueden ser diferentes según el tipo de llamada realizada. Algunos módulos solo realizan pruebas para algunos tipos de llamadas. Utilice la página de manual de cada módulo para ver ejemplos y conocer los usos y las opciones disponibles.
El orden de las entradas dentro de un tipo de llamada es importante. Esto se debe principalmente a cómo se procesan los códigos de retorno, pero en algunos casos a una acción del módulo. Cuando libpam recibe un mensaje de "hecho" o "morir", informa el resultado general al proceso de llamada.
La configuración para sudo tiene varios incluir líneas. Estas líneas le dicen a libpam para incluir todas las líneas de un tipo determinado del archivo de configuración especificado. También hay una subpila opción, que es similar en la forma en que incluye líneas de un archivo de configuración dado, pero en un "hecho" o "morir", informa a la subpila instrucción en lugar del proceso original llamando a libpam . Las versiones anteriores de PAM tenían otras variaciones sobre cómo se incluían otros archivos de configuración. Por ejemplo, cuando comencé a explorar PAM hace casi 20 años, había un módulo específico llamado con los archivos de configuración como argumento. La palabra clave "incluir" no era válida para el ReturnCode campo.
Códigos de retorno en los archivos de configuración central
El /etc/pam.d/sudo El archivo mostrado anteriormente es bastante corto. Tres de los cuatro tipos de llamadas tienen solo un incluir de otro archivo. El /etc/pam.d/system-auth El archivo es más típico de un archivo de configuración, con muchas comprobaciones para cada tipo de llamada.
$ cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
...omitted... El requerido La palabra clave es quizás la más común. Indica que el módulo debe pasar la verificación para que se devuelva un pase general a la aplicación. Sin embargo, incluso en caso de falla, se verificarán las siguientes líneas de ese tipo. Esta es una práctica de mucho tiempo de no compartir ningún motivo de una falla de autenticación. En los sistemas de hace 20 años, podría haber sido posible adivinar cómo falló la autenticación por el tiempo que tardó en fallar.
El requisito la palabra clave es similar a obligatorio en que la verificación debe pasar, pero en caso de falla, devuelve un mensaje de "morir". Requisito vamos a libpam sepa que las siguientes líneas no se verificarán y para informar al proceso de llamada de los resultados generales, en este caso, una falla.
El suficiente palabra clave es casi lo contrario de requisito . En caso de éxito, se devuelve un mensaje de "hecho" y libpam continúa y envía sus resultados generales a la aplicación que llama. Se ignoran otros resultados de este módulo y la comprobación continúa.
El suficiente palabra clave es común cuando podría haber varias formas de verificar un criterio. Por ejemplo, al verificar una contraseña, el usuario puede definirse en el /etc/passwd local. y /etc/shadow archivos, o solo pueden estar definidos en un sistema central al que se accede con sssd . El pam_unix módulo comprueba los archivos locales. Si tiene éxito, no hay necesidad de continuar y verificar los servicios centralizados. Sin embargo, si el usuario no está definido localmente, no queremos registrar una falla, queremos ignorar el resultado y probar el pam_sss módulo. Dado que el suficiente La palabra clave nunca falla realmente, es común agregar un pam_deny requerido línea después de una serie de suficiente líneas. El pam_deny módulo siempre falla como el /bin/false ejecutable.
El opcional la palabra clave es similar a suficiente en que ignora cualquier falla. Sin embargo, en caso de éxito, actúa más como el requerido palabra clave configurando un valor "ok" y continuando con las comprobaciones adicionales.
Dado que ambos requisito y suficiente pueden ser puntos de salida de la pila de módulos, el orden en el archivo de configuración es importante. Las líneas después de esas palabras clave pueden ejecutarse o no.
Códigos de retorno complejos
Más allá de la sintaxis de palabras clave simples, los códigos de retorno complejos se definen con pares clave-valor entre corchetes. El /etc/pam.d/system-auth El archivo tiene una muestra en la sección de sesión de la sintaxis más compleja.
$ cat /etc/pam.d/system-auth
...omitted...
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
Puede encontrar la sintaxis compleja que coincide con cada palabra clave en pam.conf página de manual El - que se muestra arriba también se define en la página del manual. Indica que se puede omitir el registro si el módulo no está instalado en el sistema.
¿Qué sigue?
Ahora que podemos analizar cuándo ocurre una llamada y una salida con libpam , el siguiente paso es comprender mejor el caso de uso de cada módulo. La mayoría de los módulos tienen una página de manual que explica el uso y muestra ejemplos de líneas que deberían aparecer en el pam.d Archivos de configuración. Algunos de los módulos también hacen referencia a archivos complementarios en /etc/security directorio. Esos archivos están bien comentados y, a menudo, también tienen su propia página de manual. La pam_pwquality y pam_limits los módulos son buenos ejemplos para empezar.
Resumir
En el siguiente artículo, revisaré algunos de los cambios realizados con authconfig utilidad. Si desea comenzar a editar archivos usted mismo y tiene una suscripción de aprendizaje de Red Hat, consulte el capítulo sobre PAM en el curso Red Hat Security:Linux in Physical, Virtual, and Cloud (RH415).
[ Curso gratuito en línea:Descripción general técnica de Red Hat Enterprise Linux. ]