Warum wird die Weitergabe der Geheimnisse über Umgebungsvariablen als „äußerst unsicher“ angesehen?

Das Übergeben von Geheimnissen (Kennwörtern) an ein Programm über eine Umgebungsvariable wird laut MySQL-Dokumenten als "äußerst unsicher" und als schlechte Wahl (unter Sicherheitsaspekten) für andere Ressourcen angesehen .

Ich würde gerne wissen warum - was fehlt mir? Im erwähnten MySQL-Handbuch (ich verwende dies als Beispiel) wird die Übergabe des Kennworts über die -pOption in der Befehlszeile als " unsicher " und über env var als " extrem unsichere ", fett kursive Schrift betrachtet.

Ich bin kein Experte, aber ich kenne die Grundlagen: Ein einfacher psBefehl, der sogar von einem nicht privilegierten Benutzer ausgegeben wird, liest jedes Programm zusammen mit den Befehlsparametern, während nur derselbe Benutzer (und natürlich root) die Umgebung des Prozesses lesen darf. Also, nur rootund johndoedarf die Umgebung des johndoegestarteten Prozesses lesen , während gehacktes www-dataSkript alles über liest ps.

Es muss hier eine große Sache geben, die ich vermisse - also erklären Sie mir bitte, was ich vermisse.

Mein Ziel ist es, das Geheimnis von einem Programm auf ein anderes zu übertragen, im Allgemeinen nicht interaktiv.

extrem unsicher und sollte nicht verwendet werden. Einige Versionen von ps enthalten eine Option zum Anzeigen der Umgebung laufender Prozesse. Wenn Sie auf einigen Systemen MYSQL_PWD festlegen, wird Ihr Kennwort jedem anderen Benutzer angezeigt, der ps ausführt.

Ausgearbeitet hier ( via ):

Hintergrund: Im Prozessbild werden argv [] und envp [] auf dieselbe Weise nebeneinander gespeichert. In "klassischen" UNIXes wurde / usr / bin / ps normalerweise "kmem" (oder eine ähnliche Gruppe) gesetzt, wodurch es möglich war, in / dev / kmem herumzuwühlen, um Informationen über die aktiven Prozesse zu lesen. Dies beinhaltete die Möglichkeit, die Prozessargumente UND die Umgebung aller Benutzer im System zu lesen.

Heutzutage liegen diese "privilegierten ps-Hacks" weitgehend hinter uns: UNIX-Systeme haben alle unterschiedliche Methoden zum Abfragen solcher Informationen entwickelt (/ proc unter Linux usw.). Ich denke, alle (?) Diese Hacks betrachten die Umgebung eines Prozesses nur als lesbar durch seine uid. Somit werden sicherheitsrelevante Daten wie Kennwörter in der Umgebung nicht durchgesickert.

Die alten Wege sind jedoch nicht 100% tot. Als Beispiel hier ein Beispiel von einem AIX 5.2-Computer, auf den ich Zugriff habe und der als Nicht-Root-Benutzer ausgeführt wird

[End-of-Lifed: 2009. Weiß jemand etwas über neuere AIX?]

...

Vor einiger Zeit haben wir festgestellt (im IRC?), Dass OpenBSD 5.2 genau diese Sicherheitsbedrohung aufweist, die darin besteht, dass die Umgebung an andere lokale Benutzer weitergegeben wird (dies wurde jedoch kurz nach dieser Version behoben).

[Erscheinungsjahr: 2012]

Dieser Rat in der MySQL-Dokumentation ist schlecht formuliert.

Das Übergeben eines Kennworts in einer Umgebungsvariablen ist nicht weniger sicher als das Übergeben über die Befehlszeile. Die meisten modernen Unices stellen Befehlszeilenargumente von Prozessen, jedoch nicht deren Umgebung, allen Benutzern über den psBefehl und andere ähnliche Software zur Verfügung. Es gibt Ausnahmen, aber ich habe noch nie von einem System gehört, bei dem das Gegenteil der Fall ist (Offenlegung der Umgebung ohne Offenlegung der Argumente).

Das Einfügen eines Kennworts in einen Befehl, der in eine interaktive Shell eingegeben wird, ist eine schlechte Idee, da das Kennwort im Shell-Verlauf endet. Es ist in Ordnung, wenn der Shell-Verlauf deaktiviert ist, aber Sie müssen daran denken, dies zu tun. Dies gilt unabhängig davon, ob das Kennwort als Argument oder in der Umgebung übergeben wird.

Was bei Umgebungsvariablen gefährlicher sein kann, ist, wenn die Variable an andere Prozesse übergeben wird. Das Festlegen eines Datenbankkennworts in .profilewäre beispielsweise eine sehr schlechte Idee, da es für alle Programme sichtbar wäre. Ebenso wäre es eine schlechte Idee , ein Skript export MYSQL_PWD=…in der Nähe der Spitze auszuführen, das viele Befehle darüber hinaus mysqlausführt. Wenn die Umgebungsvariable jedoch nur an mysqlBefehle übergeben wird, ist daran nichts auszusetzen.

In der MySQL-Dokumentation sollte keine Sprache verwendet werden, die die Übergabe eines Kennworts über eine Umgebungsvariable als weniger sicher bewertet als die Übergabe über ein Befehlszeilenargument. Es ist umgekehrt. (Es sei denn, die Umgebung ist auf mehr als den mysqlBefehl eingestellt, dies ist jedoch nicht das in der Dokumentation beschriebene Szenario.)

Das Hauptproblem beim Übergeben von Geheimnissen in Umgebungsvariablen besteht darin, diese Umgebung ordnungsgemäß auf den Prozess zu übertragen, der dieses Geheimnis verwendet, und es nicht an Prozesse weiterzugeben, die es nicht haben sollten.

Es ist sicher, eine Umgebungsvariable nur zum Starten eines bestimmten Prozesses festzulegen, der sie verwendet.

Aber es ist nicht global in der Shell in Umwelt Satz Geheimnisse zu sichern (für die aktuelle Sitzung) (und noch schlimmer in den globalen Startdateien der Schale ( .bash_profile, .bashrc, .profile)) , weil alle Verfahren von dieser Shell gestartet werden , dieses Geheimnis haben in ihrem Umgebung. Einige verlieren sie möglicherweise absichtlich (Malware) oder nicht (denken Sie an den Shell-Befehlsverlauf oder an ein Absturzberichtsmodul, das den gesamten Inhalt der Umgebung in einer Protokolldatei oder auf einem Remote-Server speichert).

Aus Sicht des Anwendungsentwicklers ist es leider unmöglich zu erzwingen, dass Benutzer Ihrer Anwendung die Umgebung ordnungsgemäß erfassen. Ich habe persönlich so viele Geheimnisse gesehen, die darin gespeichert sind ~/.profile.

Um eine schlechte Nutzung der Umgebung durch Benutzer zu vermeiden, ist es sicherer, keine Geheimnisse direkt in die Umgebung zu laden (um die Auswirkungen eines Lecks zu verringern) und stattdessen Umgebungsvariablen zu verwenden, um Links an den Ort zu übergeben, an dem das Geheimnis wirklich gespeichert ist: Verwenden Sie eine zusätzliche Indirektionsebene.