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).