Estrategias de seguridad para almacenar la contraseña en el disco

Question

Estoy creando un conjunto de trabajos por lotes que requieren acceso regular a una base de datos, que se ejecuta en una máquina Solaris 10. Debido a restricciones de diseño (no modificables), se nos exige utilizar un determinado programa para conectarnos a él. Dicha interfaz requiere que pasemos una contraseña de texto sin formato a través de una línea de comando para conectarnos a la base de datos. Esta es una práctica de seguridad terrible, pero estamos atrapados con ella.

Estoy tratando de asegurarme de que las cosas estén debidamente aseguradas de nuestra parte. Dado que el procesamiento es automático (es decir, no podemos solicitar una contraseña), y no puedo almacenar nada fuera del disco, necesito una estrategia para almacenar nuestra contraseña de forma segura.

Aquí hay algunas reglas básicas

1. El sistema tiene varios usuarios.
2. Podemos suponer que nuestros permisos se aplican correctamente (es decir, si un archivo con una es chmod'd a 600, no será legible públicamente)
3. No me importa que alguien con acceso de superusuario vea nuestra contraseña almacenada

Aquí es lo que tengo hasta ahora

• tienda contraseña en password.txt
• $ chmod 600 password.txt
• proceso lee desde password.txt cuando es necesario
• Buffer sobrescrito con ceros cuando ya no es necesario

Aunque estoy seguro de que hay una manera mejor.

Answer 1

Esto no es una solución para la criptografía. No importa el cifrado utilizado, la clave será igualmente accesible para el atacante. Cyrpto no resuelve todos los problemas.

chmod 400 es lo mejor, esto lo hace de solo lectura. chmod 600 es lectura de escritura, que puede o no ser un requisito. También asegúrate de que esté seleccionado por el proceso que lo necesita. Esto es realmente lo mejor que puedes hacer. Incluso si comparte la máquina con otros usuarios, no deberían poder acceder a ella. Esperemos que esta sea una máquina dedicada, en ese caso no hay mucha amenaza. SELinux o AppArmor ayudarán a fortalecer el sistema a partir de ataques de proceso cruzado/usuario cruzado.

Edit: Shread es la herramienta que necesita para eliminar archivos de forma segura.

Editar: Según los comentarios de Moron/Mike, el comando de unix ps aux mostrará todos los procesos en ejecución y el comando utilizado para invocarlos. Por ejemplo, el siguiente comando se expondrá a todos los usuarios en el sistema: wget ftp://user:password@someserver/somefile.ext. Una alternativa segura es usar la biblioteca CURL. También deberías deshabilitar tu historial de conchas. En bash puede hacer esto estableciendo una variable de entorno export HISTFILE=

Answer 2

No está lejos del mejor enfoque dadas sus limitaciones. Tienes dos problemas con los que lidiar. El primero es el almacenamiento de contraseña. El segundo es usar la contraseña de forma segura.

Tratando primero con el segundo - usted tiene un gran problema en el uso del programa de línea de comando.Usando opciones para el comando 'ps', un usuario puede ver los argumentos usados ​​al ejecutar el programa de línea de comando. Por lo que has escrito, esto contendría la contraseña en texto plano. Usted menciona que esta es una interfaz inmutable. Aun así, como programador ético, debes plantear el problema. Si se tratara de una aplicación bancaria que maneja transacciones financieras, podría considerar buscar otro trabajo en lugar de ser parte de una solución no ética.

Pasando a almacenar de forma segura la contraseña, no menciona qué idioma está utilizando para sus archivos de proceso por lotes. Si está utilizando un script de shell, entonces tiene poco recurso que codificar la contraseña en el script de shell o leerla en texto sin formato desde un archivo. De su descripción de almacenar la contraseña en un archivo separado, espero que pueda estar escribiendo un programa en un lenguaje compilado. Si es así, puedes hacerlo un poco mejor.

Si usa un lenguaje compilado, puede encriptar la contraseña en el archivo y descifrarla dentro de su programa. La clave para el descifrado residiría en el programa mismo, por lo que no podría leerse fácilmente. Además de esto, yo

• chmod 400 el archivo para evitar que otros usuarios puedan leerlo
• añadir un prefijo punto ('') en el fichero de esconderlo de directorio normales lista
• cambie el nombre del archivo para que sea menos interesante de leer
• tenga cuidado de no almacenar la clave en una cadena simple - el comando 'cadenas' imprimirá todas las cadenas imprimibles desde una imagen ejecutable de Unix.

Una vez hecho esto, los próximos pasos serían mejorar la administración de claves. Pero no llegaría tan lejos hasta que se aclare el problema 'ps'. No tiene sentido poner el tercer cerrojo en la puerta de entrada cuando planeas dejar la ventana abierta.

Answer 3

No rellene el búfer de la contraseña con ceros, esto no tiene sentido. El kernel puede decidir cambiarlo a una ubicación arbitraria en el archivo de intercambio o decir después de asignar algo de memoria que el kernel moverá las tablas de página, lo que dará como resultado otras tablas de página que contienen la contraseña mientras usted solo tiene acceso a la nueva copia.

Puede prctl (2) con PR_SET_NAME para cambiar el nombre del proceso sobre la marcha. Lamentablemente, actualmente no puedo pensar en otra forma que inyectar código en el proceso en ejecución a través de ptrace (2), lo que significa que los procesos enemigos correrán para leer la lista de procesos antes de tener la oportunidad de cambiar el nombre de los nuevos procesos:/

Alternativamente, se puede agarrar los parches grsecurity kernel, y encienda CONFIG_GRKERNSEC_PROC_USER:

Si responde S aquí, los usuarios no root se sólo será capaz de ver sus propias procesos, y les restringe a partir viendo información relacionada con la red, y viendo el símbolo del kernel y el módulo información.

Esto detendrá ps de ser capaz de ver el sistema que se ejecuta, como ps lee de /proc/<pid>/cmdline

interfaz Said nos obliga a pasar una contraseña texto plano sobre un comando línea para conectar a la base de datos. Este es una práctica de seguridad terrible, pero estamos atascados con él.

Es solo una mala práctica de seguridad debido a problemas en la arquitectura de O/S. ¿Esperaría que otros usuarios pudieran interceptar sus llamadas de sistema? No culparía a un desarrollador que cayó en esta trampa.