it-swarm-eu.dev

Zugänglichkeit von Umgebungsvariablen unter Linux

Vielleicht ist dies eine triviale Frage, aber wie zugänglich sind Umgebungsvariablen in Linux zwischen verschiedenen Benutzern?

z.B. wenn Alice ausführt

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

Kann Eve sagen, was Alice am liebsten isst? (Angenommen, Alice und Eve sind normale Benutzer und Eve hat keinen Lesezugriff auf /home/alice/fav_food.txt)

43
Yoav Aner

Verfolgen wir den Fluss der vertraulichen Daten. In dieser Analyse wird verstanden, dass alles, was Alice kann, auch Root kann. Auch ein externer Beobachter "eine Ebene höher" (z. B. mit physischem Zugriff auf Snoop auf dem Plattenbus oder im Hypervisor, wenn der Code in der virtuellen Maschine ausgeführt wird) kann möglicherweise auf die Daten zugreifen.

Zunächst werden die Daten aus einer Datei geladen. Angenommen, nur Alice hat Leseberechtigung für die Datei und die Datei ist nicht anderweitig durchgesickert, kann nur Alice cat /home/alice/fav_food.txt Erfolgreich aufrufen. Die Daten befinden sich dann im Speicher des Prozesses cat, auf den nur dieser Prozess zugreifen kann. Die Daten werden über eine Pipe vom Befehl cat an die aufrufende Shell übertragen. Nur die beiden beteiligten Prozesse können die Daten auf der Pipe sehen. Die Daten befinden sich dann im Speicher des Shell-Prozesses, wiederum privat für diesen Prozess.

Irgendwann landen die Daten in der Shell-Umgebung. Abhängig von der Shell kann dies passieren, wenn die Anweisung export ausgeführt wird oder nur, wenn die Shell ein externes Programm ausführt. Zu diesem Zeitpunkt sind die Daten ein Argument eines execve Systemaufrufs. Nach diesem Aufruf befinden sich die Daten in der Umgebung des untergeordneten Prozesses.

Die Umgebung eines Prozesses ist genauso privat wie der Rest des Speichers dieses Prozesses (von mm->env_start bis mm->env_end In der Speicherzuordnung des Prozesses). Es ist angrenzend an den Stapel des ursprünglichen Threads . Es gibt jedoch einen speziellen Mechanismus, mit dem andere Prozesse eine Kopie der Umgebung anzeigen können: die Datei environ im Verzeichnis /proc (/proc/$pid/environ). Diese Datei ist nur für den Eigentümer lesbar , wer der Benutzer, der den Prozess ausführt (für einen privilegierten Prozess ist dies die effektive UID). (Beachten Sie, dass die Befehlszeilenargumente in /proc/$pid/cmdline Andererseits für alle lesbar sind.) Sie können die Kernelquelle überprüfen, um sicherzustellen, dass dies die einzige Möglichkeit ist, die Umgebung eines Prozesses zu verlieren.

Es gibt eine andere mögliche Quelle für das Auslaufen der Umgebung: während des Aufrufs execve . Der Systemaufruf execve leckt die Umgebung nicht direkt. Es gibt jedoch einen generischen Prüfmechanismus , der die Argumente jedes Systemaufrufs protokollieren kann, einschließlich execve. Wenn also die Überwachung aktiviert ist, kann die Umgebung über Überwachungsmechanismus gesendet werden und in einer Protokolldatei enden. Auf einem anständig konfigurierten System hat nur der Administrator Zugriff auf die Protokolldatei (bei meiner Standard-Debian-Installation ist es /var/log/audit/audit.log, Nur von root lesbar und vom auditd -Dämon geschrieben, der als root ausgeführt wird ).

Ich habe oben gelogen: Ich habe geschrieben, dass die Erinnerung an einen Prozess nicht von einem anderen Prozess gelesen werden kann. Dies ist in der Tat nicht wahr: Wie alle Unices implementiert Linux den Systemaufruf ptrace . Dieser Systemaufruf ermöglicht es einem Prozess, den Speicher zu überprüfen und sogar Code im Kontext eines anderen Prozesses auszuführen. Dadurch können Debugger existieren. Nur Alice kann Alices Prozesse verfolgen. Wenn ein Prozess privilegiert ist (setuid oder setgid), kann ihn nur root verfolgen.

Schlussfolgerung: Die Umgebung eines Prozesses steht nur dem Benutzer (euid) zur Verfügung, der den Prozess ausführt .

Beachten Sie, dass ich davon ausgehe, dass es keinen anderen Prozess gibt, der die Daten verlieren könnte. In einer normalen Linux-Installation gibt es kein setuid-Root-Programm, das die Umgebung eines Prozesses verfügbar machen könnte. (Auf einigen älteren Unices war ps ein Setuid-Root-Programm, das den Kernel-Speicher analysierte. Einige Varianten zeigten die Umgebung eines Prozesses gerne allen an. Unter Linux ist ps nicht privilegiert und erhält seine Daten von /proc wie alle anderen.).

(Beachten Sie, dass dies für einigermaßen aktuelle Linux-Versionen gilt. Vor sehr langer Zeit war die Umgebung in den Tagen des 1.x-Kernels weltweit lesbar.)

Ich wollte anfangs "nein" sagen. Umgebungsvariablenwerte gelten pro Benutzer und kein anderer Benutzer kann in die Umgebung eines anderen Benutzers lesen oder schreiben. vars. Es gibt jedoch einen interessanten Leckerbissen über SO, der darauf hinweist, dass root diese Informationen zumindest über /proc/<pid>/environ Lesen kann. Diese Linux-spezifische Schnittstelle war mir erst bekannt jetzt.

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

Trotzdem sieht es so aus, als ob diese Oberfläche für andere Benutzer immer noch nicht lesbar ist, selbst wenn sie sich in denselben Gruppen befinden. Die Berechtigungen für die Umgebungsdatei sind auf 400 festgelegt, und/proc verhindert, dass chmod sie beeinflusst. Ich vermute, dass die Sicherheitsdomäne für die Trennung von Umgebungsvariablen zwischen Benutzern noch intakt ist und nicht mit normalen Mitteln umgangen werden kann.

4
logicalscope

Trotz Gilles 'theoretisch korrekter Antwort: Ich würde keine Geheimnisse in Umgebungsvariablen stecken.

  • Umgebungsvariablen werden normalerweise am oberen Rand des Prozessbaums definiert (z. B. durch $HOME/.profile).
  • Benutzer behandeln den Inhalt der Umgebung nicht als Geheimnisse.

Es reicht aus, wenn ein einzelner Prozess die Umgebungsvariablen in einer weltweit lesbaren Datei protokolliert: env >> env-traces.txt o.ä. Sie können es nicht kontrollieren.

2
slowhand

In den meisten Fällen kann ein anderer Benutzer Ihre Umgebungsvariablen nicht lesen. Die bekannte Sicherheitslücke, die eine Instanz eines Setuid-Programms als derselbe Benutzer wie jede andere Instanz eines Setuid-Programms ausführt, kann jedoch ausgenutzt werden. Dies bedeutet, dass jemand, der ein setuid-Programm ausführt und ein anderes Programm, das für denselben Benutzer setuid ist, zum Lesen aus /proc/<pid>/environ Ausnutzen kann, die Umgebungsvariablen des Programms lesen kann. Dies ist ein Grund, warum Sie für jeden Daemon, den Sie schreiben, einen neuen Benutzer verwenden sollten, anstatt den Benutzer Nobody zu missbrauchen.

wenn es keine strengen Richtlinien gibt, gibt es theoretisch eine Möglichkeit, wenn dieser Export in einem Bash-Login-Benutzerskript für Alice durchgeführt wird: Eve erstellt ein Skript zum Drucken von env und setzt SETUIDGID-Bits in chmod und gibt es dann an Alice weiter. wird dann ausgeführt. Das Skript wird unter Alices UID ausgeführt und sein Bash-Autorun wird Alices sein. Dann leckt es die Daten über stdout heraus =) Aber es muss ein sehr schwaches System-Setup geben, um solche Tricks auszuführen. Ich habe in meiner forensischen Praxis so schrecklich konfigurierte Boxen gesehen, also ist es kein Scherz.

0
Alexey Vesnin