Tracciamo il flusso dei dati riservati. In questa analisi, si capisce che tutto ciò che Alice può fare, può farlo anche root. Anche un osservatore esterno "un livello superiore" (ad es. con accesso fisico per spiare sul bus del disco o nell'hypervisor se il codice è in esecuzione nella macchina virtuale) potrebbe essere in grado di accedere ai dati.
Innanzitutto, i dati vengono caricati da un file. Supponendo che solo Alice abbia il permesso di lettura sul file e che il file non sia trapelato in altro modo, solo Alice può chiamare cat /home/alice/fav_food.txt con successo. I dati sono quindi nella memoria del cat processo, dove solo quel processo può accedervi. I dati vengono trasmessi su una pipe dal cat comando alla shell chiamante; solo i due processi coinvolti possono vedere i dati sulla pipe. I dati sono quindi nella memoria del processo della shell, anch'essi privati di quel processo.
Ad un certo punto, i dati finiranno nell'ambiente della shell. A seconda della shell, questo può accadere quando export istruzione viene eseguita o solo quando la shell esegue un programma esterno. A questo punto, i dati saranno un argomento di un execve chiamata di sistema. Dopo quella chiamata, i dati saranno nell'ambiente del processo figlio.
L'ambiente di un processo è privato tanto quanto il resto della memoria di quel processo (da mm->env_start a mm->env_end nella mappa di memoria del processo). È contiguo allo stack del thread iniziale. Tuttavia, esiste un meccanismo speciale che consente ad altri processi di visualizzare una copia dell'ambiente:il environ file nel processo /proc directory (/proc/$pid/environ ). Questo file è leggibile solo dal suo proprietario, che è l'utente che esegue il processo (per un processo privilegiato, questo è l'UID effettivo). (Notare che gli argomenti della riga di comando in /proc/$pid/cmdline , d'altra parte, sono leggibili da tutti.) Puoi controllare il sorgente del kernel per verificare che questo sia l'unico modo per divulgare l'ambiente di un processo.
C'è un'altra potenziale fonte di fuga nell'ambiente:durante il execve chiamata. Il execve la chiamata di sistema non perde direttamente l'ambiente. Tuttavia, esiste un meccanismo di controllo generico che può registrare gli argomenti di ogni chiamata di sistema, incluso execve . Pertanto, se il controllo è abilitato, l'ambiente può essere inviato tramite il meccanismo di controllo e finire in un file di registro. Su un sistema configurato in modo decente, solo l'amministratore ha accesso al file di log (sulla mia installazione predefinita di Debian, è /var/log/audit/audit.log , leggibile solo da root e scritto da auditd demone eseguito come root).
Ho mentito sopra:ho scritto che la memoria di un processo non può essere letta da un altro processo. Questo infatti non è vero:come tutti gli unix, Linux implementa il ptrace chiamata di sistema. Questa chiamata di sistema consente a un processo di ispezionare la memoria e persino di eseguire codice nel contesto di un altro processo. È ciò che consente ai debugger di esistere. Solo Alice può tracciare i processi di Alice. Inoltre, se un processo è privilegiato (setuid o setgid), solo root può rintracciarlo.
Conclusione:l'ambiente di un processo è disponibile solo per l'utente (euid) che esegue il processo .
Si noti che presumo che non ci siano altri processi che potrebbero far trapelare i dati. Non esiste un programma root setuid su una normale installazione di Linux che potrebbe esporre l'ambiente di un processo. (Su alcuni uni meno recenti, ps era un programma root setuid che analizzava parte della memoria del kernel; alcune varianti mostrerebbero felicemente l'ambiente di un processo a chiunque. Su Linux, ps non è privilegiato e ottiene i suoi dati da /proc come tutti gli altri.).
(Nota che questo vale per le versioni ragionevolmente attuali di Linux. Molto tempo fa, penso che ai tempi del kernel 1.x, l'ambiente fosse leggibile da tutto il mondo.)
Inizialmente stavo per dire "no". I valori delle variabili di ambiente sono per utente e nessun altro utente può leggere o scrivere nell'env di un altro utente. vars. Tuttavia, c'è una notizia interessante su SO che indica che root è in grado almeno di leggere queste informazioni tramite /proc/<pid>/environ . Non ero a conoscenza di questa interfaccia specifica per Linux fino ad ora.
https://stackoverflow.com/a/532284/643314
Detto questo, sembra che questa interfaccia sia ancora illeggibile per altri utenti, anche se si trovano negli stessi gruppi. I permessi sono impostati su 400 per il file environ e /proc impedisce a chmod di influenzarlo. Sospetto che il dominio di sicurezza per la separazione delle variabili di ambiente tra gli utenti sia ancora intatto e non possa essere aggirato con mezzi normali.
Nonostante la risposta teoricamente corretta di Gilles:non metterei segreti nelle variabili d'ambiente.
- Le variabili d'ambiente sono generalmente definite nella parte superiore dell'albero dei processi (ad esempio tramite
$HOME/.profile). - Gli utenti non trattano i contenuti dell'ambiente come segreti.
È sufficiente che un singolo processo registri le variabili di ambiente in un file leggibile da tutti:env >> env-traces.txt o simili. Non puoi controllarlo.