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 <mbauer at mailbox.org> 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/<UID> 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/<UID>/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         : </pipermail/attachments/20150103/5c04b12b/attachment.sig>

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/<UID> 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/<UID>/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