Sigamos el flujo de los datos confidenciales. En este análisis, se entiende que todo lo que Alice puede hacer, también lo puede hacer root. También un observador externo "un nivel superior" (por ejemplo, con acceso físico para espiar en el bus del disco o en el hipervisor si el código se ejecuta en la máquina virtual) podría acceder 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, solo Alice puede llamar a cat /home/alice/fav_food.txt exitosamente. Los datos están entonces en la memoria del cat proceso, donde solo ese proceso puede acceder a él. Los datos se transmiten a través de una tubería desde el cat comando al shell que llama; solo los dos procesos involucrados pueden ver los datos en la tubería. Luego, los datos están en la memoria del proceso de shell, nuevamente privados para ese proceso.
En algún momento, los datos terminarán en el entorno del shell. Dependiendo del shell, esto puede suceder cuando export se ejecuta la declaración, o sólo cuando el shell ejecuta un programa externo. En este punto, los datos serán un argumento de un execve llamada del sistema. 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 a la pila del subproceso inicial. Sin embargo, existe un mecanismo especial que permite que otros procesos vean una copia del entorno:el environ archivo en el proceso /proc directorio (/proc/$pid/environ ). Este archivo solo lo puede leer 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 el código fuente del kernel para verificar que esta es la única forma de filtrar el entorno de un proceso.
Hay otra fuente potencial para filtrar el entorno:durante el execve llamar. El execve La llamada al sistema no filtra directamente el entorno. Sin embargo, existe un mecanismo de auditoría genérico que puede registrar los argumentos de cada llamada al sistema, incluido execve . Entonces, si la auditoría está habilitada, el entorno puede enviarse 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 predeterminada de Debian, es /var/log/audit/audit.log , solo legible por root, y escrito por el auditd demonio ejecutándose 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 unices, Linux implementa el ptrace llamada del sistema. 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 tiene privilegios (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 ningún programa raíz setuid en una instalación normal de Linux que pueda exponer el entorno de un proceso. (En algunos dispositivos más antiguos, ps era un programa raíz setuid que analizaba parte de la memoria del kernel; algunas variantes mostrarían felizmente el entorno de un proceso a todos y cada uno. 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 las 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 entorno de otro usuario. vars. Sin embargo, hay un dato interesante sobre SO que indica que root puede al menos leer esta información a través de /proc/<pid>/environ . No conocía esta interfaz específica de Linux hasta ahora.
https://stackoverflow.com/a/532284/643314
Dicho esto, parece que esta interfaz todavía es ilegible para otros usuarios, incluso si están en los mismos grupos. Los permisos se establecen en 400 para el archivo de entorno y /proc evita que chmod lo afecte. Sospecho que el dominio de seguridad para la separación de variables de entorno entre usuarios aún está intacto y no se puede eludir por medios normales.
A pesar de la respuesta teóricamente correcta de Gilles:no pondría secretos en las variables de entorno.
- Las variables de entorno generalmente se definen cerca de la parte superior del árbol de procesos (por ejemplo, a través de
$HOME/.profile). - Los usuarios no tratan los contenidos del entorno como secretos.
Es suficiente que un solo proceso registre las variables de entorno en un archivo de lectura universal:env >> env-traces.txt o similar. No puedes controlarlo.