Módulos PAM personalizados y consideraciones de seguridad

Estoy escribiendo mi propio módulo PAM que será parte de una aplicación que estoy desarrollando, pero no estoy seguro exactamente dónde colocarlo. Mi módulo básicamente realiza autenticación a nivel de red (con otro mojo, por supuesto) similar a LDAP.

Hay muchos archivos de configuración en mi /etc/pam.d/directorio, y sé lo que hacen la mayoría de los servicios (excepto un par, como atd, polkit, ppp). Supongo que la autenticación con la pila PAM es algo como esto:

1. Ejecuta la pila según el nombre del servicio (si existe un archivo de configuración)
2. Si no está autenticado, recurra a common- *, donde * es el tipo de módulo (autenticación, cuenta, etc.)
3. Devolver el éxito o no a la aplicación de llamada (y cualquier otro dato, por supuesto)

¿Estoy en lo cierto en esta suposición? ¿Todas las plataformas tienen autenticación común, cuenta común, contraseña común y sesión común?

Si es así, estaba pensando en ponerlo en la parte superior de common- * como sufficientmódulo para que, en caso de falla, la pila PAM normal no se vea afectada. Esto es particularmente ventajoso porque puedo hacer esto programáticamente en la instalación del software.

¿Me estoy perdiendo posibles vulnerabilidades de seguridad?

No pude encontrar muy buena documentación sobre dónde integrar módulos PAM personalizados o problemas de seguridad relacionados con dónde colocar los módulos.

Cuando llama a Linux-PAM para un procedimiento de autenticación, siempre se ejecuta una y solo una pila.

La definición de la pila se busca en estos lugares; El primer intento exitoso determina qué archivo se lee:

1. el archivo con el /etc/pam.dnombre de la aplicación "nombre del servicio" (por ejemplo, sshdo gdm), o

2. el archivo /etc/pam.d/othersi no existe un archivo específico del servicio, o

3. el archivo /etc/pam.confsi el directorio /etc/pam.dno existe.

Consulte la documentación de la función pam_start para obtener más detalles.

Los archivos common- * son una convención seguida por muchas distribuciones de Linux, pero no están obligados por el software PAM en sí. Por lo general, otros archivos PAM los incluyen mediante @include declaraciones; por ejemplo, el /etc/pam.d/otherarchivo en Debian tiene el siguiente contenido:

# We fall back to the system default in /etc/pam.d/common-*
@include common-auth
@include common-account
@include common-password
@include common-session

Las mismas @includedeclaraciones también pueden ser utilizadas por archivos específicos del servicio y, de hecho, están en la configuración predeterminada en Debian. Tenga en cuenta que esto es una cuestión de configuración: ¡un administrador de sistemas puede cambiar el archivo /etc/pam.dsin incluir ningún archivo common- * en absoluto!

Por lo tanto: si su módulo PAM es específico para su aplicación, cree un archivo de servicio específico de la aplicación y llame al módulo desde allí. No , no añada automáticamente un módulo PAM de archivo de otros servicios ni a la de repliegue othersarchivo, ya que esto puede romper otras aplicaciones instaladas en el sistema. La administración de la pila de software PAM es una tarea para el administrador del sistema, no para los desarrolladores de aplicaciones.