it-swarm.it

accessibilità variabile d'ambiente in Linux

Forse questa è una domanda banale, ma quanto sono accessibili le variabili di ambiente in Linux tra utenti diversi?

per esempio. se Alice esegue

export FAVORITE_FOOD=`cat /home/alice/fav_food.txt`

Eva può dire qual è il cibo preferito di Alice? (Supponendo che sia Alice sia Eve siano utenti normali ed Eve non abbia accesso in lettura a /home/alice/fav_food.txt)

43
Yoav Aner

Tracciamo il flusso dei dati riservati. In questa analisi, si comprende che qualsiasi cosa Alice possa fare, anche root può fare. Anche un osservatore esterno "a un livello superiore" (ad es. Con accesso fisico a 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 leggere il file e che il file non sia trapelato, solo Alice può chiamare cat /home/alice/fav_food.txt correttamente. I dati sono quindi nella memoria del processo cat, dove 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 sulla pipe. I dati sono quindi nella memoria del processo Shell, di nuovo privati ​​per quel processo.

Ad un certo punto, i dati finiranno nell'ambiente 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 è privato come 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 file environ 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). (Nota 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 perdere l'ambiente di un processo.

Esiste un'altra potenziale fonte di perdite nell'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. Pertanto, se il controllo è abilitato, l'ambiente può essere inviato tramite 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 registro (sulla mia installazione Debian predefinita, è /var/log/audit/audit.log, leggibile solo da root e scritto dal demone auditd in 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 chiamata di sistema ptrace . Questa chiamata di sistema consente a un processo di ispezionare la memoria e persino di eseguire il 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 vi siano altri processi che potrebbero perdere i dati. Non esiste un programma root setuid su una normale installazione Linux che potrebbe esporre l'ambiente di un processo. (Su alcuni unici precedenti, ps era un programma root setuid che analizzava un po 'di memoria del kernel; alcune varianti avrebbero mostrato felicemente l'ambiente di un processo a tutti. Su Linux, ps è senza privilegi e ottiene il suo dati da /proc come tutti gli altri.).

(Si noti che questo vale per le versioni ragionevolmente attuali di Linux. Molto tempo fa, penso ai giorni del kernel 1.x, l'ambiente era leggibile dal mondo.)

Inizialmente stavo per dire "no". I valori delle variabili di ambiente sono per utente e nessun altro utente può leggere o scrivere nell'ambiente di un altro utente. Vars. Tuttavia, esiste un interessante punto su on SO che indica che root è in grado di leggere almeno queste informazioni tramite /proc/<pid>/environ. Fino ad ora non ero a conoscenza di questa interfaccia specifica per Linux.

https://stackoverflow.com/a/532284/643314

Detto questo, sembra che questa interfaccia sia ancora illeggibile per gli altri utenti, anche se si trovano negli stessi gruppi. Le autorizzazioni sono impostate su 400 per il file environment e/proc impedisce a chmod di influenzarlo. Ho il 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.

4
logicalscope

Nonostante la risposta teoricamente corretta di Gilles: non metterei segreti nelle variabili d'ambiente.

  • Le variabili di ambiente sono generalmente definite nella parte superiore dell'albero del processo (ad es. Attraverso $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 dal mondo: env >> env-traces.txt o simili. Non puoi controllarlo.

2
slowhand

Nella maggior parte dei casi, un altro utente non può leggere le variabili di ambiente. Tuttavia, è possibile sfruttare il noto buco di sicurezza che un'istanza di un programma setuid esegue come lo stesso utente di qualsiasi altra istanza di un programma setuid. Ciò significa che se qualcuno esegue un programma setuid e qualcun altro può sfruttare un altro programma impostato su uno 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 di nessuno.

se non ci sono politiche rigide, TEORETICAMENTE c'è un modo se questa esportazione viene effettuata in uno script utente bash-login per Alice: Eve crea uno script per stampare env e imposta i bit SETUIDGID in chmod e poi lo chiamo ad Alice, quindi esegue. La sceneggiatura sarà eseguita sotto il controllo di Alice e il suo autorun bash sarà quello di Alice. Quindi perde i dati tramite stdout =) Ma ci deve essere una configurazione di sistema molto debole per eseguire questi trucchi. Ho visto scatole così terribilmente configurate nella mia pratica forense, quindi non è uno scherzo.

0
Alexey Vesnin