Autenticación de usuario de Linux adecuada a través de aplicaciones compatibles con PAM

A medida que se encuentre, debido a la limitación del acceso a / etc / shadow, en algún nivel, su aplicación tendrá que acceder a ese archivo o acceder a algún otro módulo / servicio que tenga acceso a ese archivo. No hay forma de evitarlo si desea una solución que utilice credenciales de usuario administradas localmente (a menos que usted haga rodar las suyas por completo, algo que recomiendo evitar).

Creo que su mejor enfoque es separar el componente de autenticación. Además de tener la ventaja de limitar la superficie de exposición, tiene otra gran ventaja que aún no se ha mencionado. A partir de su publicación, parece que este software se ejecutará en sitios de clientes, algunos de los cuales pueden tener LDAP, algunos de los cuales no. Si su componente de autenticación está modularizado / separado del núcleo de su aplicación, tiene la posibilidad de obtener lo mejor de ambos mundos. Básicamente, el sitio de su cliente puede usar el método que mejor se adapte a su arquitectura.

Mantener el ambiente lo más directo y consistente posible es casi tan importante como usar la tecnología adecuada. Muchos problemas de seguridad surgen porque el entorno o la arquitectura es demasiado complicado. Los cambios que realiza alguien que no comprende completamente las implicaciones y lo siguiente que sabe es que tiene un gran agujero de seguridad.

Si escribe su aplicación de manera que pueda pasar la autenticación a un módulo externo, puede permitir que los sitios seleccionen lo que mejor se adapte a ellos. Evitan tener que administrar otra fuente de identidad, pueden garantizar la coherencia en su entorno y posiblemente obtener beneficios adicionales, como el inicio de sesión único o el mismo inicio de sesión, etc. Puede proporcionar un módulo de autenticación "predeterminado" que utilice PAM para esos sitios que no tienen LDAP o similar.

El desafío con este enfoque está en la selección o definición de la interfaz. ¿Cómo debe ocurrir la comunicación? Lo mantendría simple. Posiblemente los sockets de dominio, pero quizás otros estándares, como SAML 2.0, pueden ser útiles.

También puede interesarte este artículo, que habla sobre el uso de PAM para controlar el acceso al servicio

También, dependiendo de la plataforma de implementación, basada en redhat o debian, debe revisar SELinux y AppArmor para encontrar formas de limitar posibles problemas, como restringir los recursos a los que puede acceder un ejecutable, etc.

Otra posibilidad sería ejecutar (parte de) tu programa como root dentro de un entorno virtual. Los contenedores de Linux (lxc) hacen que esto sea liviano.

Considera que cualquier cosa que tu aplicación pueda hacer, un atacante puede hacer si tu aplicación está comprometida. Por lo tanto, no debe permitir que (la mayor parte) de su aplicación exponga nombres de usuarios válidos o realice comprobaciones de contraseñas a un ritmo ilimitado, y mucho menos cambie las contraseñas. Así que la separación de privilegios de alguna forma es el camino a seguir.

Mi preferencia es para LDAP porque es un protocolo bien conocido y ampliamente soportado y separa intrínsecamente la base de datos del usuario de la aplicación. Puede dejar que el servidor LDAP se preocupe por mantener las contraseñas seguras y hacer verificaciones correctamente, pero también sobre cosas como la limitación de velocidad, aunque su aplicación puede participar en la limitación de velocidad si tiene conocimiento adicional sobre la procedencia de los intentos de autenticación. LDAP también es más probable que sea adaptable a la autenticación federada, si desea agregar esta función.

Que sus implementaciones no tengan LDAP disponible no es un obstáculo. Incluya un servidor LDAP de código abierto de su elección y ejecútelo en un puerto personalizado y escuche solo en localhost.

Aunque se ha aceptado una respuesta aquí, no creo que sea muy buena.

  

Creando un grupo con acceso de lectura a / etc / shadow ...

No. Hace mucho tiempo, alguien tuvo la maravillosa idea de que el sistema operativo debería autenticar a los usuarios, no los programas, incluso cuando el usuario no tiene una sesión, y se le ocurrió la idea de PAM. Con PAM, el mecanismo por el cual se produce la autenticación no es la preocupación de la aplicación que busca autenticar al usuario.

  

un poco insano desde el punto de vista de seguridad para ejecutar el daemon como root

Sin embargo, la ejecución simplifica enormemente el proceso de autenticación y cambio al uid autenticado. Si este último no es un requisito, entonces podría considerar la posibilidad de invocar el paso de autenticación a través de sudo / un script setuid (solía haber un ejemplo muy simple incluido con squid) o incluso como un demonio secundario.

Hay muchas formas de probar un usuario y una contraseña; usar su (o ssh) tiene la complicación de que necesita implementar una comunicación bidireccional con un nuevo proceso, de la misma manera que lo hace 'expect'. Podría ser mucho más sencillo probar el nombre de usuario / contraseña en un buzón POP si es adverso a implementar la autenticación usted mismo.

Puede haber una forma de cambiar el uid cuando no estás root, pero probablemente sea una pregunta nueva.