2010-11-30 2 views
0

Derzeit arbeite ich an einem C-Linux-Daemon, der Benutzereingaben für eine SQL-Verbindungszeichenfolge nimmt und speichert die Informationen dann in einer lokalen Conf-Datei (Client-Seite). Der Zweck des Daemons besteht darin, Daten in einem festgelegten Intervall an eine SQL-Datenbank zu senden, in der jedes Mal, wenn der Daemon geladen wird, nach dem lokalen conf für die SQL-Verbindungszeichenfolge gesucht wird. Durch die Verwendung des Befehlszeilenarguments -c kann der Benutzer die SQL-Verbindungszeichenfolge für den Fall neu konfigurieren, dass sich die Informationen ändern. Wäre jemand bereit, einen Weg zu teilen, diese conf-Datei zu sichern, so dass es kein einfacher Text ist. Beachten Sie, dass ich immer noch auf die conf-Datei zugreifen und einlesen kann, da andere conf-Einstellungen vorhanden sind. Vielen Dank im Voraus Jungs.Best Practice für die Sicherung sensibler Daten in einer Nur-Text-Datei?

Edit: Ich plane schließlich, SSL zu verwenden, um die Daten zwischen der Client-Seite und dem SQL-Server zu übermitteln.

Antwort

6

Die (einzige?) Möglichkeit, die Datei zu sichern, besteht darin, ihre Berechtigungen so zu ändern, dass sie für den Benutzer, der den Daemon ausführt, lesbar nur sind.

Eg. Wenn Sie den Dämon als Benutzer ‚foo‘ ausgeführt werden und Gruppe ‚foo‘, sollten Sie:

chown foo.foo my-conf-file 
chmod 600 my-conf-file 

(oder gar zu 400 chmod versehentliche Änderung zu verhindern, aber ich denke, in diesem Fall Sie verlieren die -c Option Funktionalität).

HINWEIS: Denken Sie auch daran, dass es ziemlich gefährlich ist, Verbindungszeichenfolgen in der Befehlszeile zu übergeben, da sie in der Prozessliste sichtbar sind!

Sie könnten auch etwas GPG-Zeug verwenden, um die Datei zu verschlüsseln, aber ich sehe den Punkt nicht da seit dann müssen Sie den Schlüssel schützen, den Sie verwenden, um die Datei zu dekodieren, und Sie erhalten genau das gleiche Problem wie zuvor.

+0

Nun, ich maskiert die Eingabe für Informationen wie das Passwort, aber Sie machen einen gültigen Punkt, dass es gefährlich ist. Ich denke, was ich wirklich versuche zu tun, ist die Klartextdatei zu durchschauen. In diesem Zusammenhang glaube ich nicht einmal, dass der Benutzer Zugriff auf die Conf-Datei haben sollte, nur der Daemon selbst sollte dies tun. – Error1f1f

+0

Natürlich sollte der "Benutzer, der den Daemon ausführt" ein Systembenutzer sein, der nur für diesen Zweck verwendet wird, kein normaler Benutzer, der sich am System anmeldet. Der beste Weg, dies zu erreichen, besteht darin, den Daemon als root auszuführen und dann 'setuid()' in die UID des anderen weniger privilegierten Systembenutzers, der einzige, der Zugriff auf die Konfigurationsdatei hat. – redShadow

0

Wenn Sie keinen Platz haben, um Ihre Geheimnisse zu bewahren, wird Ihnen die Kryptographie nicht helfen. Wenn Ihr Daemon irgendwie in der Lage ist, ein Passwort zu entschlüsseln, ohne irgendein Geheimnis zu verwenden, dann kann dies auch jeder tun. Sie müssen sich also auf den Systemschutz verlassen, wie z. B. Dateizugriffsmodus-Flags, um Schlüssel zu behalten.

+0

Was ist mit einer nicht-Datenbank, vielleicht etwas wie NDBM? – Error1f1f

+0

@ Error1f1f: Was ist der Gewinn, den Sie von der Datenbank Nonsql erwarten? – Vovanium

Verwandte Themen