Ich denke, daß die Überladung mit "Standard-Diensten" in einer normalen und unbereinigten Installation noch eines der geringeren Probleme sind, mit denen ich Microsoft bei Windows rumschlagen muß. Meiner Ansicht nach liegen die Gefahren schon viel tiefer im Grundprinzip von Windows begraben.
Der Ausdruck "it´s no bug, it´s a feature" ist meiner Meinung nach nicht so verkehrt. Dank DDE, OLE und COM ist der Datenaustausch zwischen Anwendungen denkbar einfach implementiert, jeder Programmierer kann bei der Erstellung seiner Anwendung in diese COM impleneitieren und vielfältige Schnittstellen schaffen. Auch das Treibermodell bietet Schnittstellen für binäre Treiber von Drittanbietern.
Dies macht Windows auf der einen Seite sehr einfach handhabbar und erleichtert vieles im Umgang. Auf der anderen Seite ist aber diese tiefe Verzahnung äußerst problematisch.
Oder nehmen wir einmal die zentrale Datenbank für Konfigurationseinstellungen, die Registry. Auf der einen Seite ein immenser Vorteil, wenn (fast) alle Programme und das System selbst ihre Einstellungen an einem zentralen Ort verwalten. Auf der anderen Seite wird dieser Vorteil aber wieder mit einigen Nachteilen erkauft. Die Verwaltung der Zugriffsrechte auf einzelne Unterzweige der Registry gestaltet sich schwierig, wer bearbeitet seine Registry schon mittels regedt32 und stellt die Zugriffsrechte auf die einzelnen Zweige manuell so sicher wie möglich ein? Es gibt zwar auch von Haus aus Hilfsmittel, dies besser abzusichern, was aber selbst in Firmen selten genutzt wird.
Zusätzlich ist die Registry noch in einem proprietären Format und nicht im Klartext les- und bearbeitbar. Es gibt z.B. einen netten Proof of Concept um in der Registry mittels der NativeAPI Einträge zu erzeugen, wleche nicht sichtbar, nicht bearbeitbar und nciht löchbar sind ohen Programmierkenntnisse. Eine einfache XML-Datei als Registry würde, wenn man schon auf eine zentrale Stelle setzt, einiges transparenter machen.
Microsoft hat wohl viele Jahre wesentlich mehr Wert auf Usability als auf Sicherheit in Mehrbenutzerumgebungen gelegt wie es mir scheint. Sieht man sich die Entwicklung der Microsoftsysteme an, so ist dies auch nicht verwunderlich. Es ist noch nicht lange her, daß selbst Micrisift die Wichtigkeit des Internet entdeckt hat, viele interna des Betriebssystems und Teile des grundlegenden Designs stammen aber noch aus Zeiten, als Windows (selbst NT) höchstens in Intranets zuhause waren, welche als eher vertrauensvolle Umgebung angesehen werden können.
Es ist definitiv wesentlich schwerer und fehleranfälliger ein offen designtes Stück Software nachträglich abzusichern, als von Anfang an Sicherheit im Kern schon zu implementieren. Wenn dann noch jahrelang offensichtliche Konfigurationsschwächen nicht behoben werden muß man sich schon fragen warum. Nehmen wir doch einmal die Protokollbindung:
In Windows ist es immer noch nur mit einigen Verrenkungen möglich gewisse Protokolle (und damit meine ich nicht TCP/IP und Co, sondern RPC, DCOM, uPnP) an spezifische Adapter zu binden, oder ihre Bindung zu lösen. Dies deutet darauf hin, daß Microsoft schon beim Design dies nicht als Möglichkeit implementiert hatte und die tiefe Verzahnung von Anwendungen, Treibern und Protokollen dies problematisch machen.
Aber anstatt schwache Schnittstellen zu redesignen wird oftmals nur geflickt und dafür neue Features eingebaut.
Ich will Microsoft auf keinen Fall verteufeln, Windows 2000 ist das System auf dem ich mit Abstand am liebsten Arbeite obwohl ich einige andere kenne und Microsoft ist definitiv nicht die einzige Firma, die Fehler macht. Ich wollte nur mal zu bedenken geben, daß es zwar ein schöner (und marketingmäßig wirksamer) Vorsatz ist auf Sicherheit setzen zu wollen, aber wesentlich mehr dazu gehört, als Workarounds für Designschwächen zu finden.
xafford
