Forse questa è una domanda banale, ma quanto sono accessibili le variabili d'ambiente in Linux tra utenti diversi?
es. se Alice esegue
export FAVORITE_FOOD='cat /home/alice/fav_food.txt'
Può Eve dire qual è il cibo preferito di Alice? (Supponendo che sia Alice ed Eve siano utenti normali, sia che Eva non abbia accesso in lettura a /home/alice/fav_food.txt )
Analizziamo il flusso dei dati riservati. In questa analisi, si capisce che qualsiasi cosa che Alice può fare, può fare anche root. Anche un osservatore esterno "un livello su" (ad esempio con accesso fisico allo snoop 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 altrimenti trapelato, solo Alice può chiamare con successo cat /home/alice/fav_food.txt . I dati sono quindi nella memoria del processo cat , in cui solo quel processo può accedervi. I dati vengono trasmessi su una pipe dal comando cat alla shell chiamante; solo i due processi coinvolti possono vedere i dati sul tubo. I dati sono quindi nella memoria del processo di shell, di nuovo privato di quel processo.
Ad un certo punto, i dati finiranno nell'ambiente della shell. A seconda della shell, ciò può accadere quando viene eseguita l'istruzione export o solo quando la shell esegue un programma esterno. A questo punto, i dati saranno un argomento di una chiamata di sistema execve . Dopo quella chiamata, i dati saranno nell'ambiente del processo figlio.
L'ambiente di un processo è altrettanto privato, come il resto di memoria che di processo (da mm->env_start a mm->env_end nella mappa della memoria del processo). È contiguo con lo stack del thread iniziale . Tuttavia, v'è uno speciale meccanismo che consente ad altri processi di visualizzare una copia dell'ambiente: il file environ nel processo di /proc directory ( /proc/$pid/environ ). Questo file è leggibile solo dal proprietario , che è l'utente che esegue il processo (per un processo privilegiato, questo è l'UID efficace ). (Si noti che gli argomenti della riga di comando in /proc/$pid/cmdline , d'altra parte, sono leggibili da tutti). È possibile controllare l'origine del kernel per verificare che questo sia l'unico modo per divulgare l'ambiente di un processo.
C'è un'altra fonte potenziale di perdite l'ambiente: durante la chiamata execve . La chiamata di sistema execve non perde direttamente l'ambiente. Tuttavia, esiste un generico meccanismo di controllo che può registrare gli argomenti di ogni chiamata di sistema , incluso execve . Quindi, se il controllo è abilitato, l'ambiente può essere inviato tramite il meccanismo di controllo e finisce in un file di registro. Su un sistema decentemente configurato, solo l'amministratore ha accesso al file di log (sulla mia installazione predefinita di Debian, è /var/log/audit/audit.log , leggibili solo da root, e scritto da parte del% daemon% co_de esecuzione come root).
Ho mentito sopra: ho scritto che la memoria di un processo non può essere letta da un altro processo. Questo in realtà non è vero: come tutti gli unices, Linux implementa la auditd chiamata di sistema. Questa chiamata di sistema consente a un processo di ispezionare la memoria e persino 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ò tracciarlo.
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 Linux che potrebbe esporre l'ambiente di un processo. (Su alcuni sistemi UNIX più vecchi, ptrace era un programma setuid root che analizzato alcuni memoria del kernel; alcune varianti sarebbero felicemente visualizzare l'ambiente di un processo per ogni e qualsiasi Su Linux, ps è senza privilegi e ottiene i dati da ps come. tutti gli altri.).
(Si noti che questo si applica alle versioni ragionevolmente attuali di Linux: molto tempo fa, penso che nei giorni del kernel 1.x, l'ambiente era leggibile da tutti.)
Inizialmente avrei detto "no". I valori delle variabili d'ambiente sono per utente e nessun altro utente può leggere o scrivere sull'env di un altro utente. Vars. Tuttavia, c'è un interessante tidbit su SO che indica che root è in grado di leggere almeno questa informazione tramite /proc/<pid>/environ . Fino ad ora non ero a conoscenza di questa interfaccia specifica per Linux.
Detto questo, sembra che questa interfaccia sia ancora illeggibile per gli altri utenti, anche se si trovano negli stessi gruppi. Le autorizzazioni sono impostate a 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 i segreti nelle variabili d'ambiente.
$HOME/.profile ). È sufficiente che un singolo processo registri le variabili di ambiente in un file leggibile dal mondo: env >> env-traces.txt o simile. Non puoi controllarlo.
Nella maggior parte dei casi, un altro utente non può leggere le variabili di ambiente. Tuttavia, la ben nota lacuna di sicurezza che un'istanza di un programma setuid viene eseguita come lo stesso utente di qualsiasi altra istanza di un programma setuid può essere sfruttata. Ciò significa che se qualcuno esegue un programma setuid e qualcun altro può sfruttare un altro programma che è setuid allo stesso utente per leggere da /proc/<pid>/environ , allora possono leggere le variabili d'ambiente del programma. Questo è uno dei motivi per cui dovresti usare un nuovo utente per qualsiasi demone che scrivi invece di abusare dell'utente di nessuno.
se non ci sono regole rigide, TEORETICAMENTE c'è un modo se questa esportazione è fatta in uno script utente di bash-login per Alice: Eve crea uno script per stampare env e imposta i bit SETUIDGID in chmod e poi lo chown su Alice, poi esegue. Lo script sarà eseguito sotto l'uid di Alice e bash sarà l'esecuzione automatica di Alice. Quindi trasmette i dati tramite stdout =) Ma ci deve essere una configurazione del sistema molto debole per eseguire tali trucchi. Ho visto scatole così terribilmente configurate nella mia pratica forense, quindi non è uno scherzo.