¿Es peligroso programar un deamon llamado usuario que envía contraseñas a través de https?

3

Tengo este problema:

  • La aplicación de mi consola necesita conectarse a un servidor. Sin embargo, el servidor requiere contraseñas en texto sin formato por HTTP POST para iniciar sesión. La conexión es HTTPS.
  • La aplicación solo se llama de vez en cuando, pero no se ejecuta de forma permanente.

Ahora, no quiero que el usuario ingrese su contraseña para cada ejecución de la aplicación. Mi idea fue:

  • Cuando el usuario inicia la aplicación por primera vez, se le solicita una contraseña. Se está iniciando un nuevo deamon (es decir, un programa ejecutado por el usuario, que puede ejecutarse por varias semanas), y la contraseña ingresada se pasa directamente al deamon.
  • Para iniciar sesión en la página de inicio, la aplicación solo le dice al demonio "iniciar sesión". El demonio, que tiene la contraseña en la RAM, llama a wget para iniciar sesión en el sitio web [1].

Mi principal preocupación es que el demonio tiene la contraseña en la memoria RAM. ¿Qué peligros podrían surgir de esto?

Veo tres riesgos:

  • Alguien podría acceder a la memoria RAM. Probablemente obligando a su computadora a intercambiarla, luego presionando el botón de encendido y luego investigando su disco duro. Es posible, pero probablemente no sea efectivo.
  • El demonio podría usar archivos temporales para almacenar su memoria. Probablemente cierto para el bash? Sin embargo, si escribo un programa en C, esto no debería ser posible?
  • Alguien podría usar un script que diga "Hola demonio, soy wget / internet, dame la contraseña". Mientras llamo "/ usr / bin / wget", y mientras el usuario no sea root, creo que no será posible?

¿Algún otro problema?

Notas: [1] wget obtiene la contraseña a través de un archivo, por lo que la contraseña no está en la tabla ps . El archivo lo construiría el demonio con derechos de lectura solo para el usuario y se eliminaría después del inicio de sesión.

    
pregunta Johannes 20.12.2016 - 15:03
fuente

1 respuesta

3
  

¿Algún otro problema?

Sí, lo estás complicando demasiado.

Le sugiero que simplemente configure un ramfs o un LUKS monta y establece el permiso para que solo su aplicación tenga acceso de lectura a ese directorio. La aplicación debe ser setuid para el usuario especial, o debe tener un sudoers que permite ejecutar sudo -u specialuser secureapp .

La seguridad es la misma o mejor que lo que estás proponiendo, y sería mucho más simple de implementar.

En cuanto a su preocupación de que alguien pueda volcar la RAM, si su atacante tiene el privilegio de volcar la RAM, ya está jodido. Fugas en la contraseña es la menor de tus preocupaciones.

Si no puede filtrar la contraseña de todos modos, incluso si el atacante puede volcar la RAM, entonces no debe usar contraseñas para iniciar sesión. En su lugar, sugeriría una forma alternativa de autenticación como el token de acceso o PKI con certificado de cliente, posiblemente en un módulo de seguridad de hardware (por ejemplo, x.509 o tarjeta inteligente OpenPGP).

Si desea escribir un demonio de todos modos, y tiene un área en la RAM que contiene datos confidenciales, debe usar mmap (MAP_LOCKED) / mlock () para asignar memoria irreparable o para evitar una parte de la la memoria se ha desplazado.

Para su tercera preocupación, en lugar de que el daemon escuche en HTTP a través de TCP (AF_INET), sugiero que el daemon debería escuchar en socket de dominio Unix (AF_LOCAL) . Con el zócalo Unix, puede aplicar el permiso de archivo para restringir quién puede comunicarse con el zócalo, esto le brinda un control de acceso mucho más preciso que el TCP. Ejemplos: ssh-agent y gpg-agent se implementan utilizando sockets de Unix.

    
respondido por el Lie Ryan 20.12.2016 - 16:46
fuente

Lea otras preguntas en las etiquetas