¿Es seguro llamar a mount (2) y pasar la contraseña como parámetro?

3

Quería escribir un demonio que los usuarios puedan iniciar y que, cada 2 horas, monta automáticamente un recurso compartido de red autenticado. El demonio le pedirá al usuario la contraseña solo la primera vez, y la mantendrá mlock() ed entonces.

Mi idea fue llamar de alguna manera al programa linux mount(1) (notación de página de manual). El protocolo para el montaje (en mi caso samba) solo permite dar la contraseña a través de las opciones de montaje -o [1]. Sin embargo, pasar la contraseña como parámetro a un script de shell la hace visible en la tabla ps.

Luego, descubrí que hay una llamada al sistema linux mount(2) que toma los mismos parámetros. ¿Es seguro simplemente pasar la contraseña como texto sin formato a los parámetros de mount(2) ?

Cosas de las que me preocupo:

  • mount(2) podría implementarse llamando a un proceso donde pasa los argumentos, incluida la contraseña. Esto dejaría la contraseña en la tabla ps. Sin embargo, creo que las llamadas al sistema no lo harán.
  • mount(2) podría tener sus parámetros en una memoria que no sea mlock() ed, por ejemplo. Si el sistema se intercambia, la contraseña de texto sin formato se puede leer en el disco. No sé si se puede intercambiar una memoria de llamadas del sistema, pero como la llamada de montaje solo está activa por un corto tiempo, supongo que no es un problema real.
  • mount(2) podría (tal vez dependiendo del tipo de sistema de archivos) imprimir un error o registrar los mensajes exponiendo sus parámetros. (por ejemplo, en archivos del sistema como /var/log/messages o la salida dmesg ). Al menos, acabo de probar mount(2) con el indicador MS_SILENT y no encontré ningún registro del sistema, incluso en caso de error.

En definitiva, ¿qué tan segura es mi solución?

Notas: [1] Samba también permite archivos de autenticación de texto sin formato o escribir la contraseña en un aviso, pero no fue útil en mi caso.

    
pregunta Johannes 05.01.2017 - 15:10
fuente

1 respuesta

1
  1. mount (2) se puede implementar al llamar a un proceso es exactamente lo contrario: mount(1) es una interfaz de usuario que finalmente llama a mount(2) , que al ser una llamada del sistema pregunta al núcleo para hacer el trabajo

  2. mount (2) puede tener sus parámetros en una memoria no mlock () ed insegura, pero ¿por qué crees que la memoria mlock es segura? AFAIK root puede leer / dev / mem y / dev / kmem tan fácilmente como el contenido de la partición de intercambio ...

  3. mount (2) podría (tal vez dependiendo del tipo de sistema de archivo) imprimir mensajes de error o de registro exponiendo sus parámetros de hecho sería una amenaza para la seguridad, y no conozco ninguna red La utilidad de montaje alguna vez registra una contraseña en texto claro. De todos modos, como se dijo en 1, cualquier intento de montar el recurso compartido de red terminará finalmente en una llamada mount(2) para que no pueda evitarlo.

TL / DR: es mucho más seguro llamar a mount(2) que iniciar un subproceso para llamar a mount(1) porque los parámetros pasados al comando de subproceso serán accesibles a través de la tabla de proceso y se pueden mostrar con ps con Las opciones apropiadas y el procesamiento de la condición de error serán mucho más simples.

    
respondido por el Serge Ballesta 05.01.2017 - 18:02
fuente

Lea otras preguntas en las etiquetas