From mbauer at mailbox.org Sat Jan 3 13:14:37 2015 From: mbauer at mailbox.org (Mathias Bauer) Date: Sat, 3 Jan 2015 13:14:37 +0100 Subject: Mehrere Login-Sessions auf einem Rechner: einen gemeinsamen gpg-agent oder pro Session einen eigenen? In-Reply-To: <871tnq4304.fsf@helmutwaitzmann.news.arcor.de> References: <20141220145832.GA6290@mailbox.org> <871tnq4304.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <20150103121437.GA30760@mailbox.org> * Helmut Waitzmann schrieb am Di, 23. Dez 2014, um 19:47 (+0100): > Mathias Bauer writes: > > [denselben gpg-agent für alle Sessions (X, Konsole) eines > > Benutzers verwenden, Option --write-env-file] > > > > - Du legst eine Datei fest, z. B. /tmp/gpg-agent-info; lokal per > > Rechner, nicht per NFS in HOME. > > Wie garantierst du, dass diese Datei dem Benutzer gehört, der > gerade ein gpg-agent starten will? Das folgende Setting ist beim Start des gpg-agent sinnvoll. Die Quellen von gpg-agent habe ich mir jetzt nicht angesehen. 1. Das Verzeichnis von $FILE ist sicher. 2. $FILE braucht evtl. gar nicht zu existieren. Für Punkt 1 hast Du drei Möglichkeiten: 1. Installiere libpam-tmpdir. Das sichert Dir ein Verzeichnis /tmp/user/ mit sicherem Eigentümer und Berechtigungen. 2. Überprüfung selbst basteln mit den üblichen Verdächtigen aus den coreutils: also z. B. mit stat -c ... 3. Kombination aus 1. und 2. Dann wäre FILE=/tmp/user//gpg-agent-info sicher. > > - Jeder Start von gpg-agent nutzt sie als Argument der Option > > --write-env-file, also so > > eval $(gpg-agent --daemon --sh --write-env-file "$FILE") > > Hat gpg-agent Vorkehrungen gegen Race‐Conditions? Der > Textabschnitt aus dem gpg-agent‐Manual > > gpg-agent --daemon --enable-ssh-support \ > --write-env-file "${HOME}/.gpg-agent-info" > > This code SHOULD only be run ONCE PER USER SESSION to > initially fire up the agent. In the example the optional > support for the included Secure Shell agent is enabled and > the information about the agent is written to a file in the > HOME directory. Note that by running gpg-agent without > arguments you may test whether an agent is already running; > however such a test may lead to a race condition, thus it is > not suggested. [Hervorhebungen von mir] > legt nahe, dass es keine verlässliche Möglichkeit gibt, Race‐Conditions > durch (nahezu) gleichzeitigen Start mehrerer Sessions zu vermeiden: > gpg-agent ohne Parameter zu starten, um zu testen, ob er bereits läuft, > scheidet damit aus. Auch steht im Manual nichts davon, dass der Agent > die mit --write-env-file angegebene Datei gegen gleichzeitige > Schreibzugriffe sperrt und dass er, falls er die Datei bereits gesperrt > vorfindet, sich einfach beendet. Für das geplante Szenario kannst Du das vernachlässigen. Bei libpam-tmpdir wird der Start der Session abgebrochen, wenn es zu (merkwürdigen) Fehlern kommt. Bei manueller Prüfung per Skript musst Du selbst die Notbremse ziehen. > > - Für Sessions auf der Konsole werden in ~/.bashrc Prüfungen > > eingebaut: Existiert $FILE? Wenn nein, starte Agent. > > Wie bekommt man das race‐condition‐frei hin? Gar nicht. Das ist aber auch nicht nötig. Deswegen musst Du im Vorfeld so viel abprüfen, damit Du *vor* den kritischen Anweisungen gpg-agent --daemon --sh --write-env-file "$FILE" . "$FILE" oder kombiniert eval $(gpg-agent --daemon --sh --write-env-file "$FILE") auf der sicheren Seite bist. Beispielsweise könntest Du in den Startskripten $FILE auch einfach löschen wenn "irgend etwas" nicht "passt" und dann fortfahren. Dann hast Du zwar vielleicht mehrere laufende Agenten, aber über die Umgebungsvariablen nur genau *einen*, der für Anwendungen *dieser* Session auch erreichbar ist. > > Wenn ja, lese $FILE und prüfe ob mit den Angaben in $FILE ein > > Agent "erreichbar" ist. Wenn nein, starte einen. > > Wie verhindert man, dass, während ein Session "$FILE" gerade > liest, ein zweites "$FILE" gerade beschreibt? Die "Session" schreibt nichts, gpg-agent schreibt. Und nur die Startskripte lesen, damit sich die Umgebungsvariablen einrichten können. Für eine laufende Session ist die Datei wertlos. In welchem Szenario kommt der beschriebene Fall denn vor? Oder anders gefragt, wie schnell bist Du denn z. B. bei manuellen parallelen Logins? > Wie verhindert man, dass bei zwei Sessions der Test, ob bereits > ein Agent läuft, negativ ausfällt, und deshalb jedes der beiden > Sessions einen Agenten startet? Durch mehr Prüfungen :-) ... natürlich nur bis zu einem gewissen Grad. Du musst abwägen, ob Du ggf. einfach einen zweiten Agenten startest oder ob Du beim Start der Session etwas länger warten musst, weil die Shellskripte eben ihre Zeit benötigen. > Für die Lösung des gpg-agent‐Problems brauche ich entweder die > Möglichkeit, einen gemeinsamen Agenten für alle Sessions eines > Benutzers auf demselben Rechner race‐condition‐frei zu starten > oder einen eigenen Agenten für jede Sitzung race‐condition‐frei > zu beenden. Das Problem sind parallele Sessions eines Benutzers. Im Folgenden sind A und B Konsolen- und/oder X-Sessions: 1. Session: AAAAAAAA 2. Session: BBBB 1. Session: AAAA 2. Session: BBBB Relevante Fragen: - Wann wird ein gpg-agent gestartet und FILE geschrieben? - Wann werden die Umgebungsvariablen für die Session erstellt, also $FILE gelesen? - In welchem Zeitraum sind die Umgebungsvariablen überhaupt gültig (weil es (noch) einen dazugehörigen gpg-agent gibt)? und natürlich: - Welche Folgen hat der Start eines zweiten gpg-agent für den Benutzer? Es ist das übliche Bequemlichkeit vs. Sicherheit. Die Fokussierung auf den Punkt Race conditions führt jetzt nicht weiter. Wer sollte denn Akteur sein und was kann passieren? Und hat man in diesen Szenarien evtl. nicht größere Probleme, als den Start von gpg-agent? Viele Grüße Mathias -- CAcert Assurer - See http://www.CAcert.org for details or ask me GnuPG/OpenPGP: B100 5DC4 9686 BE64 87E9 0E22 44C3 983F A762 9DE8 -------------- n�chster Teil -------------- Ein Dateianhang mit Bin�rdaten wurde abgetrennt... Dateiname : nicht verf�gbar Dateityp : application/pgp-signature Dateigr��e : 760 bytes Beschreibung: nicht verf�gbar URL : From mkesper at fsfe.org Tue Jan 6 14:22:27 2015 From: mkesper at fsfe.org (Michael Kesper) Date: Tue, 06 Jan 2015 13:22:27 -0000 Subject: Mehrere Login-Sessions auf einem Rechner: einen gemeinsamen gpg-agent oder pro Session einen eigenen? In-Reply-To: <20150103121437.GA30760@mailbox.org> References: <20141220145832.GA6290@mailbox.org> <871tnq4304.fsf@helmutwaitzmann.news.arcor.de> <20150103121437.GA30760@mailbox.org> Message-ID: <54ABD8A6.9020605@fsfe.org> Hallo zusammen, Am 03.01.2015 um 13:14 schrieb Mathias Bauer: > * Helmut Waitzmann schrieb am Di, 23. Dez 2014, um 19:47 (+0100): >> Wie garantierst du, dass diese Datei dem Benutzer gehört, der >> gerade ein gpg-agent starten will? > > Das folgende Setting ist beim Start des gpg-agent sinnvoll. Die > Quellen von gpg-agent habe ich mir jetzt nicht angesehen. > > 1. Das Verzeichnis von $FILE ist sicher. > 2. $FILE braucht evtl. gar nicht zu existieren. > > Für Punkt 1 hast Du drei Möglichkeiten: > > 1. Installiere libpam-tmpdir. Das sichert Dir ein Verzeichnis > /tmp/user/ mit sicherem Eigentümer und Berechtigungen. > 2. Überprüfung selbst basteln mit den üblichen Verdächtigen aus > den coreutils: also z. B. mit stat -c ... > 3. Kombination aus 1. und 2. > > Dann wäre FILE=/tmp/user//gpg-agent-info sicher. Eine weitere Möglichkeit wäre noch die Verwendung von systemd und PrivateTmp=yes http://0pointer.de/blog/projects/security.html Viele Grüße Michael