Wer Samba-Promi ist oder auch nur an den Code gewordenen Ergebnissen der neuen Microsoft-Dokumentation interessiert war, blieb Mitte April eigentlich nur der Weg nach Göttingen. Auf der Samba XP herrschte dann auch die entsprechende Dichte an Entwicklern, Projektleitern und CIFS-Neuigkeiten.
Jeremy Allison ist einer der von Google bezahlten Kernentwickler des Projekts und für Samba 3.2 zuständig. In seinem Vortrag skizzierte er die technischen Updates und sprach von Aufräumarbeiten und der Verschlüsselung des Datenverkehrs. Als Beispiel für Code-Cleanups nannte er die »pstrings«, das sind Datenstrukturen, die das Projekt intern etwa für Pfadnamen verwendet (Abbildung 1). Ihre feste Länge beträgt 1024 Bytes, was bei UTF-8-Kodierung zu Pfadnamen führen kann, die nur noch 170 Zeichen lang sind. Allison beschrieb diese Situation als "bequem, aber verkehrt" und hat mehrere Tausend Codestellen auf ein dynamisches Modell umgestellt.
Abbildung 1: Eine der vielen Stellen, an denen die Entwickler so genannte Pstrings im Code korrigiert haben. Die auf 1024 Bytes festgelegten Strings sorgten für Probleme bei Pfadnamen.
"Die konkrete Arbeit war nicht sonderlich spektakulär, aber die Erkenntnisse daraus erstaunlich", erläuterte Allison. So habe er festgestellt, dass die Entwickler an vielen Stellen die alten Strukturen nicht genutzt und stattdessen individuellen Code verwendet hätten. Dies sei nun vereinheitlicht. Außerdem beobachtete er, dass die Geschwindigkeit erheblich von der verwendeten Malloc-Methode abhängt. Die besten Ergebnisse erzielte er mit Googles Tcmalloc-Methode, die sich aber in Umgebungen ohne Threads sogar noch der internen Entwicklung Alloc_mmap von Samba-Entwickler Andrew Tridgell geschlagen geben musste.
Die gemeinsame Arbeit von Allison und Entwickler Steve French (Abbildung 3) diente einer CIFS-kompatiblen Transportverschlüsselung für Samba. Diese Verschlüsselung ist ein neues Feature, bislang ließen sich Pakete nur signieren. Durch die Einsicht in die Dokumentation von Microsoft waren die beiden Coder in der Lage, die so genannten Unix-Extensions zu nutzen, die es mittels neuer SMB-Opcodes erlauben, eigene Funktionen in den Verbindungsaufbau (»trans2«) einzufügen. Das machte Änderungen am API überflüssig. Der resultierende Code läuft unter Samba 3 wie im Entwicklungszweig Samba 4.
Für den Austausch der Sicherheitsfunktionen dient das in RFC 2743 definierte GSSAPI (Generic Security Services Application Programming Interface), da es sich leicht mit den Kerberos-Token integrieren lässt, die ohnehin in Samba zum Einsatz kommen. Allison betonte, dass Kerberos keine Voraussetzung für die Verschlüsselung sei. Weiterhin implementierten die Entwickler Kompatibilität zum SSPI (Security Support Provider Interface), der Microsoft-Variante von GSSAPI.
In einer Demonstration führte Allison die Verschlüsselung live vor. Während ein normales SMB-Paket jeweils mit der Codesequenz »0xff, \'S\', \'M\', \'B\'« markiert ist, meldet sich ein verschlüsseltes Paket als »0xff, \'E\'« und mit zwei Oktetten, die den Sicherheitskontext festlegen. In späteren Implementationen bleibt damit die Möglichkeit offen, unterschiedliche Verschlüsselungsparameter von verschiedenen Clients zu unterstützen. Nach der Autorisierungsphase »trans2« sind damit alle Pakete verschlüsselt.
Die Semantik einer SMB-Sitzung verändert sich dadurch nicht, nutzt ein Client aber eine vom Server verlangte Verschlüsselung nicht, erhält er erst bei Leseversuchen einen Zugriffsfehler. Vorsicht ist beim Einsatz der Lösung aber geboten: Wenn die Verschlüsselung auf Basis eines Benutzeraccounts geschieht und mehrere Anwender dessen Credentials einsetzen, kann der Besitzer der Credentials seine Anmeldeparameter für eine Man-in-the-Middle-Attacke nutzen. Allison sagte, dass Systemverwalter in diesem Fall den Maschinenaccount des Clients konfigurieren sollten.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
