Windows oder Linux: Welches Betriebssystem ist sicherer?

Unter Unix ist „Impersonation“ stark eingeschränkt. Das ist eine Technologie, die es ermöglicht, dass ein Server-Prozess eine neue Identität annimmt, sobald sich ein Client-Prozess korrekt identifiziert hat. Unix erlaubt ausschließlich Prozessen, die unter root laufen, eine neue Identität anzunehmen.

Typisches Beispiel ist ein SSH-Server: Der SSH-Prozess läuft zunächst unter root. Sobald ein Benutzer eine Verbindung aufbaut, wird ein Tochterprozess geforkt. Nach korrekter Anmeldung nimmt der zweite Prozess die Identität des Benutzers an, siehe Bild 3. Das ist sicherheitstechnisch einwandfrei, bedingt jedoch einen eigenen Prozess für jeden angemeldeten Benutzer, was einen erheblichen Ressourcenbedarf erfordern kann.

Sicherheit versus Performance: Oft ein Konflikt

Aus Performancegründen wäre es besser, mit nur einem Server-Prozess und verschiedenen Threads zu arbeiten. Windows bietet die Möglichkeit, einzelnen Threads eines Prozesses unterschiedliche Identitäten zuzuweisen. Ein Server-Prozess kann dabei zunächst mit einem Account gestartet werden, der sehr wenige Rechte besitzt. Nötig ist nur das Recht „Annehmen der Clientidentität nach Authentifizierung“. Ein Client-Prozess, der sich identifiziert, bekommt anschließend einen eigenen Thread, der die Identität des Client-Benutzers annimmt. Für einen FTP-Server bedeutet das beispielsweise, dass der Thread einfach versucht, eine Datei zu öffnen, die der Benutzer anfordert. Hat der Benutzer keine Berechtigung, so erhält der Thread einen Access-Denied-Fehler.

Auch unter Unix ließe sich eine Lösung mit Posix-Threads realisieren. Dann bleibt aber nur die Möglichkeit, alle Threads der Benutzer mit der Root-Identität laufen zu lassen. Ob ein Benutzer berechtigt ist, auf eine Datei zuzugreifen, muss der Server-Prozess selbst prüfen.

Auf den ersten Blick scheint ein Multi-Threaded-Server unter Windows sicherer als unter Unix. Hat ein Server unter Unix einen Bug, etwa einen Pufferüberlauf, so kann es gelingen, beliebigen Code auszuführen. Unter Unix hat ein Angreifer dann sofort Root-Rechte, während er unter Windows nur die Rechte des angemeldeten Benutzers, in diesem Fall seine eigenen, besitzt.

Das reicht jedoch aus, um beispielsweise einen Botnetz-Client zu installieren. Dies kann ein Benutzer absichtlich, aber auch versehentlich veranlassen, wenn sein eigener Rechner ebenfalls verseucht ist.

Ferner bedeutet eine Lösung mit Threads sowohl unter Unix als auch unter Windows immer das Risiko, dass Passwörter ausspioniert werden, wenn ein Angreifer eine Sicherheitslücke ausnutzen kann. Gelingt ihm die Ausführung von Code, so hat er Zugriff auf den gesamten virtuellen Speicher des Prozesses, auch auf den Master-Thread, der die Nutzer authentifiziert.

In der Praxis hat das dazu geführt, dass Entwickler von Serveranwendungen unter Unix meist mit Tochterprozessen arbeiten. Wird die Client-Server-Verbindung von einem eigenen Prozess verwaltet, kann ein Angreifer grundsätzlich keine Verbindungsdaten anderer Clients ausspionieren. Unter Windows werden häufig Thread-Lösungen implementiert.

Fehlerfreie Security-Architektur nicht realistisch

Beide Lösungen sind dann sicher, wenn sich in der Server-Anwendung, in den verwendeten Libraries und im Betriebssystem keine Bugs befinden, die ein Angreifer ausnutzen kann. Das ist jedoch nicht realistisch.

Schaut man in die Details einiger Serveranwendungen, dann finden sich erhebliche Mängel. Ein Beispiel ist SMB-Filesharing. Windows verwendet eine Thread-Lösung mit den beschriebenen Risiken. Unter Unix verwendet Samba eine Implementierung mit Tochterprozessen.

Solange Dateien geöffnet sind, arbeitet jeder Tochterprozess mit der Identität des Benutzers. Wenn nach einer gewissen Zeit der Inaktivität die TCP-Verbindung geschlossen wird, kehrt dieser Tochterprozess zur Identität root zurück. Bild 4 zeigt, dass der Samba-Prozess 3251 zunächst unter dem Benutzer root gestartet wird, danach unter tinah arbeitet und später wieder unter root.

Dass dies überhaupt möglich ist, hängt damit zusammen, dass die unterschiedlichen Unix-Versionen eine Rückkehr zum ursprünglichen Benutzer unterschiedlich handhaben. Linux verbietet explizit eine Rückkehr zur root, wenn man das Posix-API setuid verwendet. Andere APIs, beispielsweise seteuid und setreuid, erlauben dies explizit.

Der Prozess arbeitet zwar nur dann unter root, wenn keine Client-Verbindung geöffnet ist, jedoch kann eingeschleuster Schadcode jederzeit die Root-Rechte ohne Legitimierung anfordern. Sicherheitstechnisch hätte Samba Privilege-Separation implementieren müssen, wie es beispielsweise OpenSSH vormacht. Das bedingt natürlich zwei Prozesse pro Client-Verbindung und damit mehr Ressourcen.

SMB-Filesharing sperrt fast jede Firefall in der Default-Konfiguration. Die Implementierungen in Windows und Linux sind vom Konzept her nicht sicher genug, wenngleich aus völlig unterschiedlichen Gründen. Performanceüberlegungen stehen im Vordergrund. Einen SSH-Zugang ermöglicht hingegen jeder Hoster über das Internet. Security-Purist Theo de Raadt stellt bei OpenSSH eine saubere Security-Architektur vor jede Performanceüberlegung.