Cyrus SASL sasldb konfigurieren

Abstract

Die Cyrus SASL sasldb ist schnell eingerichtet. Sie bietet eine einfache Möglichkeit Systemaccounts von Dienstaccounts, z.B. für SMTP Authentifizierung, zu trennen.

Die Cyrus SASL sasldb ist schnell eingerichtet. Sie bietet eine einfache Möglichkeit, Systemaccounts von Dienstaccounts, z.B. für SMTP Authentifizierung, zu trennen. Zusätzlich ermöglicht sie die Nutzung von shared secret-Mechanismen. Dazu müssen die Kennworte im Klartext abgespeichert werden. Richtig gemacht, läßt sich das damit verbundene Risiko brauchbar begrenzen.

Die sasldb ist die hauseigene Datenbank des Cyrus SASL authentication frameworks. Sie ist eine Berkeley DB und hält Daten vor, die für Authentifizierung erforderlich sind. Cyrus SASL bringt zu ihrer Verwaltung die Kommandozeilen-Werkzeuge saslpasswd2 und sasldblistusers2 mit. Sie dienen dazu, SASL Accounts anzulegen, zu listen, zu ändern und auch sie zu entfernen.

User in sasldb2 erstellen

Der folgende Aufruf von saslpasswd2 legt einen SASL Account user@example.com in der sasldb2 an:

% saslpasswd2 -c -u example.com user
Password: **********
Again (for verification): **********

Note

Sollte die Datenbank zu diesem Zeitpunkt noch nicht existieren, legt der erste Aufruf von saslpasswd2 sie automatisch an.

sasldb2-Datenbank sicher betreiben

Eine sasldb legt Passworte im Klartext-Format ab. Das geschieht mit Absicht. Plaintext-Passworte (siehe auch: Simple Authentication and Security Layer) sind Voraussetzung für die Nutzung sogenannter shared-secret-Mechanismen.

Die Berkeley DB verfügt nicht über eigene Mechanismen (z.B. Authentifizierung von Identität, Ort von dem aus zugegriffen wird, etc.) mit denen sie den Zugriff auf die Daten gezielt steuern kann. Jeder System-Account, der die Datenbank-Datei lesen darf, kann folglich die SASL Identitäten mitsamt Plaintext-Passworten auslesen.

Für einen hinreichend sicheren Betrieb sollten deshalb Lese-Rechte auf die sasldb restriktiv gehandhabt werden. Nur Datenbank-Admins und Applikationen, die über diese Datenbank SASL-Authentifizierung anbieten, sollten die Datenbank-Datei lesen dürfen!

Debianisierte Systeme setzen diesen Zugriffschutz um, indem sie /etc/sasldb2 an den User root und die Gruppe sasl übergeben. Wer auch immer dann /etc/sasldb2 lesen möchte, muss in der Gruppe sasl sein.

% chgrp sasl /etc/sasldb2 && chmod 640 /etc/sasldb2
% ls -l /etc/sasldb2
-rw-r----- 1 root sasl 12288 Sep  2 23:24 /etc/sasldb2

Diese Lösung ist effektiv und einfach im Alltag umsetzbar.

sasldb-User auflisten

Nach dem Anlegen eines SASL-Kontos ist es sinnvoll, zur Kontrolle die Daten der neuen Identität auszulesen. Für diese Aufgabe sieht Cyrus SASL das Kommandozeilen-Werkzeug sasldblistusers2 vor:

% sasldblistusers2
user@example.com: userPassword

Stellvertretend für das Passwort wird an dieser Stelle der Wert userPassword ausgegeben. Wie schon erwähnt, täuscht die Ausgabe nur darüber hinweg, dass das Kennwort unverschlüsselt in der Datenbank abgelegt wurde.

Ein strings /etc/sasldb2 gibt die Daten preis. Wer es genauer wissen will, erstellt ein Dump der Datenbank mit dem Berkeley DB eigenen Tool db_dump. Das Beispiel zeigt das Kennwort secret im Klartext:

% db_dump -d a /etc/sasldb2
In-memory DB structure:
hash: 0x90000 (open called, read-only)
meta_pgno: 0
h_ffactor: 0
h_nelem: 1
h_hash: 0x7fb6eac2cd50
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
page 0: hash metadata: LSN [0][1]: level 0
      magic: 0x61561
      version: 9
      pagesize: 4096
      type: 8
      metaflags 0
      keys: 0 records: 0
      free list: 0
      last_pgno: 2
      flags: 0
      uid: 61 6 b8 0 1 8 0 0 72 ec 7a be 85 74 0 0 0 0 0 0
      max_bucket: 1
      high_mask: 0x1
      low_mask:  0
      ffactor: 0
      nelem: 1
      h_charkey: 0x5e688dd1
      spare points:
      1 (1) 1 (2) 0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 0 (0)
      0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 0 (0)
      0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 0 (0)
      0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 0 (0)

page 1: hash: LSN [0][1]: level 0
      prev:    0 next:    0 entries:    2 offset: 4059
      [000] 4066 len:  29 data: user\0example.com\0userPassword
      [001] 4059 len:   6 data: secret
page 2: hash: LSN [0][1]: level 0
      prev:    0 next:    0 entries:    0 offset: 4096

Tip

db_dump ist übrigens perfekt geeignet, um die Berkeley DB von einem alten Host in ein flat file zu exportieren, und es auf dem neuem Host mittels db_load wieder in eine neue /etc/sasldb2 zu schreiben. So lassen sich Berkeley-Inkompatibilitäten beim Versionswechsel zwischen verschiedenen Berkeley DBs elegant umgehen.

SMTP AUTH mit sasldb konfigurieren

Cyrus SASL ist ein Framework, das vielen Applikationen Hilfe bei der Authentifizierung leisten kann. Für die Kommunikation zwischen Applikation und Cyrus SASL bindet sie die Bibliothek libsasl ein.

Unterschiedliche Applikationen können unterschiedliche Anforderungen an Authentifizierung haben. Damit Cyrus SASL diesen entsprechen kann, läßt es für jede Applikation eine eigene Konfiguration. Die passende Konfigurationdatei sucht Cyrus SASL in $application_name.conf. Den Wert für $application_name übermittelt eine Applikation während der Initialisierung der libsasl. Die Cyrus SASL Bibliothek sucht nach $application_name.conf an folgenden vorgegebenen Standardpfaden:

/usr/lib64/sasl2
/usr/lib/sasl2
/etc/sasl2

Findet es eine $application_name.conf, beendet es seine Suche. Dann versucht es den Inhalt einzulesen und vorhandene Konfigurationsangaben zu laden.

In Postfix findet SMTP-Authentifizierung in der SMTP-Session statt. Für die SMTP-Session ist der Postfix smtpd Daemon zuständig. Er identifziert sich gegenüber libsasl als smtpd. Cyrus SASL sucht folglich an den Standardpfaden nach einer smtpd.conf.

Note

Debianisiere Systeme liefern ein gepatchtes Postfix aus. Dort wird die Konfigurationsdatei in /etc/postfix/sasl/smtpd.conf erwartet.

Wir wollen die sasldb2 verwenden und geben in /etc/postfix/sasl/smtpd.conf an, es soll auxilliary property plugins verwenden, und aus der Familie dieser Plugins das Plugin sasldb:

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: plain login cram-md5 ntlm

Die Liste der Mechanismen können wir, weil die Kennwörter im Klartext abgespeichert sind, um die shared secret-Mechanismen CRAM-MD5 und NTLM ausweiten.

Note

DIGEST-MD5 ist auch ein shared secret-Mechanismus, der gerne eingesetzt wird. Er ist allerdings deprecated und sollte nicht mehr genutzt werden.

Patrick Koetter, 28. October 2014