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 Festplattenbus 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, wieder 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 für einen Systemaufruf execve . 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 die Speicherzuordnung des Prozesses). Es ist zusammenhängend mit dem 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 kann nur von ihrem Eigentümer gelesen werden, der der Benutzer ist, 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 der einzige Weg ist, ein Leck zu verursachen die Umgebung eines Prozesses.

Es gibt eine weitere mögliche Quelle für das Auslaufen der Umgebung: während des Aufrufs ausführen. 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 den Überwachungsmechanismus gesendet werden und in einer Protokolldatei landen. 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 von geschrieben der Daemon auditd , der als root ausgeführt wird).

Ich habe oben gelogen: Ich habe geschrieben, dass der Speicher eines Prozesses 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 Kernelspeicher analysierte. Einige Varianten zeigten die Umgebung eines Prozesses gerne allen an. Unter Linux ist ps unprivilegiert und bezieht seine Daten wie alle anderen von / proc .)

(Beachten Sie, dass dies für einigermaßen aktuelle Linux-Versionen gilt. Vor sehr langer Zeit denke ich in der 1.x Kerneltage war die Umgebung weltlesbar.)

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 bei SO, der darauf hinweist, dass root diese Informationen zumindest über / proc / <pid> / environ lesen kann. Diese Linux-spezifische Schnittstelle war mir bisher nicht bekannt.

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

Vor diesem Hintergrund Es sieht 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.

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

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

Es reicht aus, wenn ein einzelner Prozess die Umgebungsvariablen in a protokolliert Weltlesbare Datei: env >> env-traces.txt oder ähnliches. Sie können es nicht steuern.

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 auf denselben Benutzer eingestellt ist, aus / proc / <pid> / environ lesen 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 dann chown es ist zu Alice, dann fü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.