Quizás esta es una pregunta trivial, pero ¿qué tan accesibles son las variables de entorno en Linux entre diferentes usuarios?
por ejemplo si Alice ejecuta
export FAVORITE_FOOD='cat /home/alice/fav_food.txt'
¿Puede Eve saber cuál es la comida favorita de Alice? (Suponiendo que tanto Alice como Eve sean usuarios normales, y Eve no tiene acceso de lectura a /home/alice/fav_food.txt )
Vamos a rastrear el flujo de los datos confidenciales. En este análisis, se entiende que cualquier cosa que Alice pueda hacer, la raíz también puede hacer. También un observador externo "un nivel arriba" (por ejemplo, con acceso físico a snoop en el bus de disco, o en el hipervisor si el código se está ejecutando en la máquina virtual) podría tener acceso a los datos.
Primero, los datos se cargan desde un archivo. Suponiendo que solo Alice tenga permiso de lectura en el archivo y que el archivo no se filtre de otra manera, solo Alice puede llamar a cat /home/alice/fav_food.txt con éxito. Los datos están entonces en la memoria del proceso cat , donde solo ese proceso puede acceder a ellos. Los datos se transmiten a través de un conducto desde el comando cat al shell que realiza la llamada; Solo los dos procesos involucrados pueden ver los datos en la tubería. Los datos están entonces en la memoria del proceso de shell, de nuevo privado a ese proceso.
En algún momento, los datos terminarán en el entorno del shell. Dependiendo del shell, esto puede suceder cuando se ejecuta la instrucción export , o solo cuando el shell ejecuta un programa externo. En este punto, los datos serán un argumento de una llamada al sistema execve . Después de esa llamada, los datos estarán en el entorno del proceso hijo.
El entorno de un proceso es tan privado como el resto de la memoria de ese proceso (de mm->env_start a mm->env_end en el mapa de memoria del proceso). Es contiguo con la pila del hilo inicial . Sin embargo, existe un mecanismo especial que permite que otros procesos vean una copia del entorno: el archivo environ en directorio /proc ( /proc/$pid/environ ). Este archivo es solo legible por su propietario , que es el usuario que ejecuta el proceso (para un proceso privilegiado, ese es el UID efectivo) ). (Tenga en cuenta que los argumentos de la línea de comando en /proc/$pid/cmdline , por otro lado, son legibles por todos). Puede auditar la fuente del kernel para verificar que esta es la única manera de filtrar el entorno de un proceso.
Hay otra fuente potencial para filtrar el entorno: durante la execve call . La llamada al sistema execve no pierde directamente el entorno. Sin embargo, hay un mecanismo de auditoría genérico que puede registrar los argumentos de cada llamada al sistema , incluyendo execve . Por lo tanto, si la auditoría está habilitada, el entorno se puede enviar a través del mecanismo de auditoría y terminar en un archivo de registro. En un sistema configurado decentemente, solo el administrador tiene acceso al archivo de registro (en mi instalación por defecto de Debian, es /var/log/audit/audit.log , solo legible por root y escrito por el daemon auditd que se ejecuta como root).
Mentí arriba: escribí que la memoria de un proceso no puede ser leída por otro proceso. De hecho, esto no es cierto: como todos los dispositivos, Linux implementa la llamada al sistema ptrace . Esta llamada al sistema permite que un proceso inspeccione la memoria e incluso ejecute código en el contexto de otro proceso. Es lo que permite que existan los depuradores. Solo Alice puede rastrear los procesos de Alice. Además, si un proceso es privilegiado (setuid o setgid), solo la raíz puede rastrearlo.
Conclusión: el entorno de un proceso solo está disponible para el usuario (euid) que ejecuta el proceso .
Tenga en cuenta que asumo que no hay otro proceso que pueda filtrar los datos. No hay un programa root setuid en una instalación normal de Linux que pueda exponer el entorno de un proceso. (En algunas unidades antiguas, ps era un programa raíz de setuid que analizaba algo de la memoria del kernel; algunas variantes mostrarían felizmente el entorno de un proceso para todos. En Linux, ps no tiene privilegios y obtiene sus datos de /proc como todos los demás.).
(Tenga en cuenta que esto se aplica a versiones razonablemente actuales de Linux. Hace mucho tiempo, creo que en los días del kernel 1.x, el entorno era legible para todo el mundo).
Inicialmente iba a decir "no". Los valores de las variables de entorno son por usuario y ningún otro usuario puede leer o escribir en el env de otro usuario. vars Sin embargo, hay un dato interesante sobre SO que indica que la raíz puede al menos leer esta información a través de /proc/<pid>/environ . No tenía conocimiento de esta interfaz específica de Linux hasta ahora.
Dicho esto, parece que esta interfaz aún es ilegible para otros usuarios, incluso si están en los mismos grupos. Los permisos se establecen en 400 para el archivo environ y / proc evita que chmod lo afecte. Sospecho que el dominio de seguridad para la separación de variables de entorno entre los usuarios aún está intacto y no se puede omitir por medios normales.
A pesar de la respuesta teóricamente correcta de Gilles: no pondría secretos en las variables de entorno.
$HOME/.profile ). Es suficiente que un solo proceso registre las variables de entorno en un archivo legible para todo el mundo: env >> env-traces.txt o similar. No puedes controlarlo.
En la mayoría de los casos, otro usuario no puede leer sus variables de entorno. Sin embargo, se puede aprovechar el conocido agujero de seguridad que una instancia de un programa setuid ejecuta como el mismo usuario que cualquier otra instancia de un programa setuid. Esto significa que si alguien ejecuta un programa setuid y alguien más puede explotar otro programa que está configurado para el mismo usuario para leer desde /proc/<pid>/environ , entonces pueden leer las variables de entorno del programa. Esta es una de las razones por las que deberías usar un nuevo usuario para cualquier daemon que escribas en lugar de abusar del usuario "nadie".
si no hay políticas estrictas, teóricamente hay una manera si esta exportación se realiza en un script de usuario de inicio de sesión de bash para Alice: Eve crea un script para imprimir env y establece bits SETUIDGID en chmod y luego lo envía a Alice, luego se ejecuta. El script se ejecutará bajo el uid de Alice y su ejecución automática de bash será la de Alice. Luego filtra los datos a través de stdout =) Pero debe haber una configuración del sistema muy débil para realizar tales trucos. Vi unas cajas tan mal configuradas en mi práctica forense, así que no es una broma.