Auf der SambaXP in Göttingen skizzierten Entwickler und Projektleiter die nächsten Schritte für den Produktionszweig Samba 3.2 des populären CIFS-Dateiservers. Zu den technischen Updates gehören einige Aufräumarbeiten und die Verschlüsselung des Datenverkehrs. Organisatorisch will sich das Projekt in deutschen Händen straffer organisieren.
In einem Vortrag berichtete Jeremy Allison, einer der von Google bezahlten Kernentwickler des Projektes, von technischen Neuerungen. Als Beispiel für Code-Cleanups nannte er so genannte “pstrings”, Datenstrukturen, die das Projekt intern unter anderem für Pfadnamen verwendet. Ihre Länge beträgt fest 1024 Bytes, was bei einer UTF-8-Kodierung zu Pfadnamen führen kann, die nur noch 170 Zeichen lang sind. Da Allison diese Situation als “bequem, aber verkehrt” empfand, hat er innerhalb eines Monats mehrere Tausend Codestellen auf ein dynamische Modell umgestellt. “Die konkrete Arbeit war nicht sonderlich spektakulär, aber die Erkenntnisse daraus waren erstaunlich”, erläuterte der Entwickler. So stellte er fest, dass die Entwickler an vielen Stellen die alten Strukturen gar nicht genutzt und stattdessen individuellen Code verwendet hatten. Dies ist nun vereinheitlicht. Weiterhin stellte er fest, dass die Geschwindigkeit erheblich von der verwendeten Malloc-Methode abhängt. Die besten Ergebnisse erzielte er mit Googles Tcmalloc-Methode, die in ungethreadeten Umgebungen sogar noch von einer internen Entwicklung “Alloc_mmap” von Samba-Entwickler Andrew Tridgell geschlagen wurde.
Etwas länger benötigte Allison zusammen mit Entwickler Steve French, um eine CIFS-kompatible Transportverschlüsselung in Samba einzubauen. Dies stellt ein völlig neues Feature dar, weil Anwender bislang Pakete nur signieren, aber nicht verschlüsseln konnten. Durch die Einsicht in die Dokumentation von Microsoft waren die beiden in der Lage, sie so genannten Unix-Extensions zu nutzen, die mittels neuer SMB-Opcodes erlaubt, eigene Funktionen in den Verbindungsaufbau (“trans2”) einzufügen. So mussten sie keine Änderungen am API vornehmen, der Code läuft unter Samba 3 wie im Entwicklungszweig Samba 4.
Für den Austausch der Sicherheitsfunktionen nutzen die Entwickler das in RFC 2743 definierte GSSAPI (Generic Security Services Application Programming Interface), da es sich leicht mit den Kerberos-Token, die ohnehin in Samba genutzt werden, integrieren lässt. Allison betonte jedoch, 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 Code-Sequenz 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, etwa unterschiedliche Verschlüsselungsparameter von verschiedenen Clients zu unterstützen. Nach der Autorisierungsphase “trans2” sind damit alles Pakete verschlüsselt, wie alle Teilnehmer live verfolgen konnten. Die Semantik einer SMB-Sitzung hat sich dadurch nicht verändert, 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 diese zur Verschlüsselung einsetzen, kann der Besitzer der Credentials seine eigenen Anmeldeparameter für eine Man-in-the-Middle-Attacke nutzen. Allison weist daher darauf hin, dass Systemverwalter in diesem Fall den Maschinenaccount konfigurieren sollten.
Weiterhin verkündete Allison, dass das bald erscheinende Samba 3.2 IPv6 unterstützen wird. Dazu hat er alle Zugriffe auf Datenstrukturen zum Netzzugriff auf IPv4 in Wrapper verpackt und entsprechende Aufrufe für den seit längerem angekündigten IP-Nachfolger implementiert. Die Arbeit von einem weiteren Monat habe sich gelohnt, da sich Samba-Anbieter etwa in den USA und in anderen Ländern nun an öffentlichen Ausschreibungen beteiligen könnten, die diese Funktion vorschreiben.
Als letzte Neuerung stellte Allison die Möglichkeit vor, größere SMB-Pakete zu versenden. Dazu nutzen die Samba-Entwickler nun sieben bislang ungenutzte Bits in NetBIOS-Paketen. Die oberhalb von TCP versendeten Pakete können nun 16 MByte lang werden – im Gegensatz zu bisher einigen KByte. Wenn auch die Clients diese Erweiterung nutzen, etwa mit der unter Linux vom Kernel bereitgestellten Funktion “recvfile”, sind erhebliche Leistungssteigerungen möglich, versprach Allison.
Neben den technischen Neuerungen will sich das Samba-Team nun auch straffer organisieren: So übernimmt mit der von der Sernet GmbH für diesen Zweck freigestellte Karolin Seeger von Gerold Carter die Rolle der Releasemanagerin. Das nächste stabile Produktionsrelease 3.2 stellte das Projekt dann für den Sommer in Aussicht. Es wird dann komplett unter der GPLv3 stehen. Im Anschluss daran strebe man darüber hinaus, wie einige andere Projekte auch, einen halbjährlichen Release-Zyklus an.
