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.

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.

Verschlüsselter Transport

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.

Live-Demonstration

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.

IPv6 inklusive

Außerdem verkündete Allison, dass Samba 3.2 IPv6 unterstützt. Dazu habe er alle Zugriffe auf Datenstrukturen zum Netzzugriff auf IPv4 in Wrapper verpackt und entsprechende Aufrufe für den Nachfolger implementiert. Samba-Anbieter, etwa in den USA, können sich nun an öffentlichen Ausschreibungen beteiligen, die IPv6 vorschreiben.

Als letzte Neuerung stellte er die Möglichkeit vor, größere SMB-Pakete zu versenden. Dazu nutzen die Samba-Entwickler sieben bislang ungenutzte Bits in Netbios-Paketen. Die oberhalb von TCP versendeten Pakete können nun 16 MByte lang sein – im Gegensatz zu bisher einigen KByte. Wenn auch die Clients diese Erweiterung nutzen, etwa mit der unter Linux vom Kernel bereitgestellten Funktion »recvfile«, seien erhebliche Leistungssteigerungen möglich.

Wenn Samba 3.2 wie geplant im Sommer erscheint, kümmert sich bereits die vom deutschen Samba-Experten Sernet zu diesem Zweck freigestellte Karolin Seeger (Abbildung 2) um die Belange rund um den Server. Als neue Release-Managerin löst sie Gerold Carter in dieser Rolle ab.

Abbildung 2: Übernimmt die Aufgabe der Release-Managerin: Karolin Seeger.

Abbildung 3: Steve French hat sich der Transportverschlüsselung angenommen.

Samba 4 sucht Helfer

Andrew Bartlett hat in Göttingen den aktuellen Stand der “Forschungsversion 4.0” von Samba vorgestellt und Entwickler sowie Anwender aufgerufen das Projekt zu unterstützen. Samba 4 ist eine von Grund auf neu konzipierte Umsetzung des SMB-Protokolls, die sich nahtlos in Windows-Umgebungen mit Active-Directory-Anschluss integrieren soll. Nach mehreren Jahren Arbeit ist nun die Basisfunktionalität vorhanden. Bartlett nannte den aktuellen Stand eine “funktionale Alphaversion”.

Das Team habe viel getan, damit Entwickler und Anwender leichter mitwirken können, unterstrich Bartlett. So setze das Buildsystem nun auf klassisches GNU-Make statt auf diverse Perl-Skripte. Außerdem komme an verschiedenen Stellen rund um das Projekt Python zum Einsatz, da die Produktivität dieser Sprache die Entwickler überzeugt habe.

Aufräumarbeiten bei der internen Datenbank LDB zählte Bartlett zu den Änderungen unter der Haube. Außerdem sei die Integrität von Verzeichniseinträgen verbessert und die Metadaten für die Replikation seien besser aufbereitet.

Der Anwender, der ein LDAP-Backend konfiguriert, darf sich auf ein Skript freuen, das die aufwändige Steuerungsdatei nun selbstständig zusammenstellt. Zusätzlich lässt sich Samba 4 mit Microsofts MMC-Konsole steuern und verwalten. Sicherheitsverantwortliche dürfte interessieren, dass in Samba 4 der Heimdahl-1.1-Standard und erweiterte ACLs implementiert sind. Bartlett stellte für Ende 2008 eine erste Betaversion in Aussicht. (uba)