Verfolgen wir den Fluss der vertraulichen Daten. In dieser Analyse wird davon ausgegangen, dass alles, was Alice tun kann, auch root tun kann. Auch ein externer Beobachter „eine Ebene höher“ (z. B. mit physischem Zugriff zum Schnüffeln 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. Unter der Annahme, dass nur Alice Leserechte für die Datei hat und die Datei nicht anderweitig durchgesickert ist, kann nur Alice cat /home/alice/fav_food.txt aufrufen erfolgreich. Die Daten befinden sich dann im Speicher der cat Prozess, auf den nur dieser Prozess zugreifen kann. Die Daten werden über eine Pipe von der cat übertragen Befehl an die aufrufende Shell; 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 Umgebung der Shell. Je nach Shell kann dies passieren, wenn die export -Anweisung ausgeführt wird, oder nur dann, wenn die Shell ein externes Programm ausführt. An diesem Punkt sind die Daten ein Argument von execve Systemaufruf. 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 im Speicherabbild des Prozesses). Er grenzt an den Stack des ursprünglichen Threads an. Es gibt jedoch einen speziellen Mechanismus, der es anderen Prozessen ermöglicht, eine Kopie der Umgebung anzuzeigen:der environ Datei im /proc des Prozesses Verzeichnis (/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 sind für alle lesbar.) Sie können den Kernel-Quelltext prüfen, um zu überprüfen, ob dies der einzige Weg ist, die Umgebung eines Prozesses zu verlieren.
Es gibt eine weitere potenzielle Quelle für das Durchsickern der Umgebung:während der execve Anruf. Die execve Der Systemaufruf leckt nicht direkt in die Umgebung. Es gibt jedoch einen generischen Prüfmechanismus, der die Argumente jedes Systemaufrufs protokollieren kann, einschließlich execve . Wenn die Überwachung aktiviert ist, kann die Umgebung also durch den Überwachungsmechanismus gesendet werden und in einer Protokolldatei landen. Auf einem anständig konfigurierten System hat nur der Administrator Zugriff auf die Protokolldatei (in meiner Standard-Debian-Installation ist es /var/log/audit/audit.log , nur von root lesbar und von auditd beschrieben Daemon läuft als root).
Ich habe oben gelogen:Ich habe geschrieben, dass das Gedächtnis eines Prozesses nicht von einem anderen Prozess gelesen werden kann. Dies ist in der Tat nicht wahr:Wie alle Unices implementiert Linux den ptrace Systemaufruf. Dieser Systemaufruf ermöglicht es einem Prozess, den Speicher zu inspizieren und sogar Code im Kontext eines anderen Prozesses auszuführen. Es ermöglicht Debuggern zu existieren. Nur Alice kann Alices Prozesse verfolgen. Außerdem kann nur root verfolgen, wenn ein Prozess privilegiert ist (setuid oder setgid).
Fazit: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 offenlegen könnte. (Auf einigen älteren Unices, ps war ein Setuid-Root-Programm, das Kernel-Speicher analysierte; Einige Varianten würden die Umgebung eines Prozesses gerne jedem und allen zeigen. Unter Linux ps ist unprivilegiert und bekommt seine Daten von /proc wie alle anderen.).
(Beachten Sie, dass dies für halbwegs aktuelle Linux-Versionen gilt. Vor sehr langer Zeit, ich glaube, in den 1.x-Kernel-Tagen, war die Umgebung weltweit lesbar.)
Ich wollte zunächst "nein" sagen. Umgebungsvariablenwerte gelten pro Benutzer, und kein anderer Benutzer kann die Umgebung eines anderen Benutzers lesen oder schreiben. var. Es gibt jedoch einen interessanten Leckerbissen auf 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
Abgesehen davon sieht es so aus, als ob diese Benutzeroberfläche für andere Benutzer immer noch nicht lesbar ist, selbst wenn sie sich in denselben Gruppen befinden. Die Berechtigungen sind für die Environ-Datei auf 400 gesetzt und /proc verhindert, dass chmod sie beeinflusst. Ich vermute, dass die Sicherheitsdomäne für die benutzerübergreifende Trennung von Umgebungsvariablen noch intakt ist und nicht mit normalen Mitteln umgangen werden kann.
Trotz Gilles' theoretisch richtiger Antwort:Ich würde keine Geheimnisse in Umgebungsvariablen stecken.
- Umgebungsvariablen werden normalerweise am Anfang des Prozessbaums definiert (z. B. durch
$HOME/.profile). - Benutzer behandeln die Inhalte der Umgebung nicht als Geheimnisse.
Es reicht aus, dass ein einzelner Prozess die Umgebungsvariablen in einer allgemein lesbaren Datei protokolliert:env >> env-traces.txt oder ähnliches. Sie können es nicht kontrollieren.