Passwort-Agent für Skripte

11/02/2010 - 20:10 von Michael Schuerig | Report spam
Ich habe einige existierende und potenzielle Skripte, die für ihre
Aufgabe Passwörter benötigen. Darunter ein Backup-Skript, dass ein
verschlüsseltes Volume mountet und (noch potenziell) ein Skript, das
regelmàßig per cron meine Kontoumsàtze herunterladen soll.

Diesen Anwendungsfàllen ist gemein, dass ich die benötigten Passwörter
nicht unverschlüsselt in einer Datei speichern möchte.

Meine derzeitige Vorstellung ist, dass die Skripte Zugriff auf einen
Schlüsselbund bekommen, in dem die benötigten Passwörter enthalten sind.
Wobei dieser Zugriff zunàchst von einem Benutzer für eine bestimmte Zeit
oder die Dauer der Session freigeschaltet werden muss.

Der Schlüsselbund selbst könnte unter Linux, wenn ich mich nicht irre,
mit Hilfe des Kernel Key Retention Service implementiert werden:

"This service allows cryptographic keys, authentication tokens, cross-
domain user mappings, and similar to be cached in the kernel for the use
of filesystems and other kernel services."

Noch unklar ist mir, wie ich sicherstellen kann, dass nur genau die
Skripte bestimmte Passwörter ausgehàndigt bekommen, für die ich das auch
erlaubt habe. Ich kann für jedes Skript eine Signatur speichern und mit
dieser die Skriptdatei überprüfen, aber das ist nur eine sehr schwache
Prüfung, weil insbesondere Skriptteile, die mit einem Include-
Mechanismus geladen werden, nicht berücksichtigt werden. Außerdem kann
ich nicht sicher sein, dass das gerade ausgeführte Skript überhaupt der
Skriptdatei entspricht, wie sie gerade im Dateisystem liegt. (Diese
Probleme sind nicht spezifisch für Skripte, sondern betreffen natürlich
ebenso binàre Programme und Libraries.)

Mit etwas weiterem Überlegen, lassen sich da noch beliebig viele
Schwierigkeiten finden, nehme ich an. Das könnte ein Zeichen dafür sein,
dass ich das falsche Problem zu lösen versuche oder es an der falschen
Stelle tue. Ich könnte entscheiden, dass ich mich um Integritàt gar
nicht kümmere, sondern dies einem eigenen Werkzeug überlasse.

Am liebsten wàre mir, wenn es schon eine Lösung für meine zu Anfang
geschilderten Anwendungsfàlle gàbe. Wenn nicht, bin ich mit meinen
beschriebenen Ideen auf dem richtigen Weg?

Michael

Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/
 

Lesen sie die antworten

#1 Markus Wichmann
12/02/2010 - 10:58 | Warnen spam
Michael Schuerig () schrieb:

Ich habe einige existierende und potenzielle Skripte, die für ihre
Aufgabe Passwörter benötigen. Darunter ein Backup-Skript, dass ein
verschlüsseltes Volume mountet und (noch potenziell) ein Skript, das
regelmàßig per cron meine Kontoumsàtze herunterladen soll.

Diesen Anwendungsfàllen ist gemein, dass ich die benötigten Passwörter
nicht unverschlüsselt in einer Datei speichern möchte.

Meine derzeitige Vorstellung ist, dass die Skripte Zugriff auf einen
Schlüsselbund bekommen, in dem die benötigten Passwörter enthalten sind.
Wobei dieser Zugriff zunàchst von einem Benutzer für eine bestimmte Zeit
oder die Dauer der Session freigeschaltet werden muss.

Der Schlüsselbund selbst könnte unter Linux, wenn ich mich nicht irre,
mit Hilfe des Kernel Key Retention Service implementiert werden:

"This service allows cryptographic keys, authentication tokens, cross-
domain user mappings, and similar to be cached in the kernel for the use
of filesystems and other kernel services."

Noch unklar ist mir, wie ich sicherstellen kann, dass nur genau die
Skripte bestimmte Passwörter ausgehàndigt bekommen, für die ich das auch
erlaubt habe. Ich kann für jedes Skript eine Signatur speichern und mit
dieser die Skriptdatei überprüfen, aber das ist nur eine sehr schwache
Prüfung, weil insbesondere Skriptteile, die mit einem Include-
Mechanismus geladen werden, nicht berücksichtigt werden. Außerdem kann
ich nicht sicher sein, dass das gerade ausgeführte Skript überhaupt der
Skriptdatei entspricht, wie sie gerade im Dateisystem liegt. (Diese
Probleme sind nicht spezifisch für Skripte, sondern betreffen natürlich
ebenso binàre Programme und Libraries.)

Mit etwas weiterem Überlegen, lassen sich da noch beliebig viele
Schwierigkeiten finden, nehme ich an. Das könnte ein Zeichen dafür sein,
dass ich das falsche Problem zu lösen versuche oder es an der falschen
Stelle tue. Ich könnte entscheiden, dass ich mich um Integritàt gar
nicht kümmere, sondern dies einem eigenen Werkzeug überlasse.

Am liebsten wàre mir, wenn es schon eine Lösung für meine zu Anfang
geschilderten Anwendungsfàlle gàbe. Wenn nicht, bin ich mit meinen
beschriebenen Ideen auf dem richtigen Weg?

Michael




Hmm...

also, letztlich ist ja auch das Kernel Key Retention System nix weiter
als der Versuch, vorhandene Informationen zu verstecken. Letztlich
müssen die Passwörter irgendwann entschlüsselt werden um dann benutzt
werden zu können. Also kannst du sie nur so gut wie möglich verstecken.

Bei Linux ist doch die Idee eines "root": Er darf alles und kann alles.
Also kann er auch Schlüssel aus dem Kernel Key Retention System
auslesen.

Darum würde ich mich damit nicht aufhalten. Meine Idee wàre:

- Du schreibst die Passwörter in eine Datei.
- Du erstellst einen neuen Nutzer, sagen wir "dummy".
- Als "dummy" erstellst du einen GPG-Schlüsselsatz.
- Mit diesem Pubkey verschlüsselst du die Passwortdatei.
- Anschießend legst du die Passwortdatei ins Home-Verzeichnis von
"dummy".
- Setzt die Rechte auf 400.
- Die Skripte machst du SetUID-dummy. (Wurde das nicht bei Skripten
ignoriert? Dann muss evtl. ein Binàr-Wrapper her.)
- In den Skripten wird die Datei nur im Speicher entschlüsselt, geparst,
benutzt.

Dieses Verfahren hat den Vorteil, dass ein feindliches Eindringen auf
deinen Rechner dem Angreifer immer noch nicht Zugriff auf die Passworte
gibt. Dazu muss er erst root werden. Und wenn er root ist, darf er eh
alles, inklusive Schlüssel aus dem Kernel laden.

HTH,
Markus
Progress (n.): Process through which USENET evolved from smart people in
front of dumb terminals to dumb people in front of smart
terminals.

news://freenews.netfront.net/ - complaints:

Ähnliche fragen