Professor Klaus Brunnstein aus Hamburg gilt als vehementer Kritiker des Unix-Betriebssystems. Seine militante Äußerung von früher, er würde einen Kreuzzug gegen Unix führen, will er aber heute modifiziert verstanden wissen: Unix ist nicht prinzipiell, sondern in Details zu kritisieren. Die aber sind aus sicherheitstechnischen Aspekten entscheidend. Das Interview, das COMPUTERWOCHE-Redakteur Jan-Bernd Meyer führte, ergänzt kontrapunktisch die Aussagen von Ingo Wieneke von AT&T.
CW: Professor Brunnstein, ist Unix nun ein unsicheres Betriebssystem oder nicht?Brunnstein: Unix hat im Kern selber keine Mechanismen mit denen man kontrollieren kann wie der Zugang ist. Es hat überdies eine höchst gefährliche Dateistruktur. Man kann sagen es ist ein verteiltes vernetztes System mit unabhängigen Directories. Durch diese Verteilung hat es noch eine gewisse Sicherheit weil es kein zusammenfassendes Kriterium gibt. Das Problem bei Unix ist aber sein Root- und das System-Administrator-Konzept.
CW: Sie meinen, die Zugriffsmöglichkeiten auf das Betriebssystem bergen die Risiken?
Brunnstein: Es gibt eine Analyse über die Unix-Sicherheit. Darin ist man zu dem Ergebnis gekommen, daß man Unix wegen seiner intrinsischen Eigenschaften nicht so sicher machen kann, daß es für kritische Anwendungen, also sensitive Anwendungen im militärischen Bereich, im Finanz-, im Medizin- und im Industriebereich einsetzen kann. Bereits 1976 wurde geschrieben, man darf es da nicht einsetzen. An dieser Situation hat sich bis heute nichts geändert. Auch Posix nicht, denn bei Posix hat man vergessen, in das Betriebssystem hinein Sicherheitsspezifikationen festzulegen. Jetzt versucht man die Sicherheit von außen als Shell zu implementieren.
CW: Noch einmal gefragt: Es gibt keine sichere Unix Version?
Brunnstein: Es gibt ein angeblich sicheres Unix-System, das Secure-Unix von Gould. Das hat aber auch die üblichen Schwächen mit dem Baumzugriff auf die Dateien.
CW: Außerdem gibt es noch den Unsicherheitsfaktor Mensch. . .
Brunnstein: Sie können nicht eine Systemsicherheit von der Zuverlässigkeit eines Menschen abhängig machen. Grundsätzlich kann man sagen: wenn Sie ein System haben, bei der die Sicherheit sozusagen auf der Schale aufsitzt, dann haben Sie Probleme. Das gilt für IBM, für ACL. Das gilt für die Security-Schalen, die heute bei Unix verwendet werden und auch für PC-Schutz-Software auf MS-D0S. Wenn Sie eine Schale außen rum machen, und es gelingt mit Systemkenntnissen oder wie auch immer, an der Schale vorbeizukommen, dann sind Sie im Besitz aller Eigenschaften einschließlich der Möglichkeit, die Integrität, die Sicherheit, die Verfügbarkeit des Systems zu beeinträchtigen. Das gelingt bei MS-DOS genauso wie bei Unix.
CW: Die Shells sind also die Troublemaker bei Unix?
Brunnstein: Da Unix ja eine ganze Menge Shells anbietet, hat man sich bemüht, Metashells zu implementieren. Shells, mit denen man zum Beispiel Electronic Mail verfügbar macht oder mit denen Programme spezifiziert werden können. Diese Shells sind natürlich Einbruchswerkzeuge. Um Systemzugriff zu bekommen, müssen die jeweiligen Zugriffsrechte recht hoch angesiedelt sein. Deshalb sagt man ja auch, daß Probleme bei den Systemadministratoren entstehen, nicht bei den normalen Anwendern.
CW: Sie sprachen von den Zugriffsmöglichkeiten auf das Betriebssystem: Was halten Sie denn dann von Fernwartungsoptionen ?
Brunnstein: Wenn man ein Softwareprodukt fernwarten will, wünscht man sich als Softwareproduzent natürlich, die Software zu übertragen im Quellcode, die Compiler und auch die Systeminstallationsprogramme remote induzieren zu können und das Programm zu starten. Diese Mail Funktion mit Debug wurde als Tool entwickelt in Berkeley, weil man auf diese Weise neue Systemversionen distribuieren kann. Daß die Systemintegrität dabei gefährdet ist, haben sie nicht gesehen.
CW: Wie reagieren denn die Anwender auf so etwas? Für die sind solche Mechanismen doch sehr benutzerfreundlich ".
Brunnstein: Die Anwender waren relativ kritisch im Xerox Park und haben gesagt, das wollen wir nicht. Das haben die Entwickler denen dann auch zugesichert. Trotzdem hat Berkeley in sein Produkt dieses Debug-Feature eingebaut.
CW: Welche Vorteile sehen Sie denn bei dem Unix-Betriebssystem?
Brunnstein: Unix ist ein hervorragendes Entwicklungssystem für Software. Deshalb würde ich sagen: Was man braucht, wären eigentlich zwei Unixe. Ein Unix, mit dem man Software entwickeln kann. Und ein Unix, mit dem man auf Unix entwickelte Programme so fährt, daß sie hinterher auch nicht mehr verändert werden können. Das heißt, ich würde diese ganzen Send-Mail-Funktionen mit Debug-Features rausnehmen.
CW: Gibt es denn Entwicklungen für ein solchermaßen modifiziertes Unix-System?
Brunnstein: Wir entwickeln in Hamburg ein solches Unix. Wir haben allerdings kein Standard-Unix genommen. Also weder Posix, noch Unix System V, sondern Minix. Das ist eine Variante von Tannenbaum aus Holland. Das haben wir ausgekernt und daraus praktisch ein Produktions-Betriebssystem gemacht. In diesem Unix, das Ende des Jahres wohl fertig sein wird, können Sie nur ein Programm installieren und das fährt ab, da können Sie keine Virusattacke drauf machen, weil die Änderung des Programmes nicht zulässig ist. Sie können das Programm nur de- und neuinstallieren.
CW: Gibt es grundsätzliche Eigenschaften, die in einem sicheren Unix-System unbedingt vorhanden sein müßten?
Brunnstein: Was im Unix generell fehlt, was in allen sicheren Systemen sein muß, ist der sogenannte Audit-Mechanismus.
CW: Was hat man denn von einer Meldung zu halten, die aktuelle Unix-Version von AT&T, das Unix. System V/MLS, Multilevel Security, Release 3.1 habe jetzt nach der Orange-Book-Klassifikation die Einstufung B1 bekommen. Kann man nun behaupten, hier existiere eine Unix-Version, die sicher ist?
Brunnstein: Ich vermute, daß AT&T grundsätzlich sagt, Send-Mail mit Debug-Funktionen gibt es bei uns nicht. Allerdings frage ich mich, wie man einen Anwender hindern will, die Debug-Funktionen mit dem Betriebssystem zu installieren. Aber ich muß auch sagen: B1 ist zweifelsfrei schon ein relevanter Schritt vorwärts, verglichen mit heute maximal C2. Ich bin der Meinung, die Stufe, bei der es eigentlich interessant wird, ist B2.
CW: Nun sind ja Sicherheitsprobleme keine Spezialität nur von Unix. . . Brunnstein: Alle virtuellen Systeme, die den physischen Zugriff auf Plattenspeicher und auf Speicherhierarchien und Prozesse umsetzen in logische Anforderungen, die sind sicherer als alle physikalischen Zugriffsmechanismen, zu denen zweifelsfrei Unix auch gehört. VMS ist insoweit natürlich sicherer, aber es ist dahingehend nicht vergleichbar, als das Unix System oft kleiner gemacht werden kann als ein Vax-System. VM und MVS in den neuen Versionen sind in diesem Sinne virtuell. Allerdings hat sich gezeigt, daß sie zu wenig leistungsfähig, zu schwerfällig sind. Grundsätzliche Schwierigkeit: Wir haben heute keine Referenzmechanismen, und wahrscheinlich werden die in der Forschung auch erst entstehen. Das BMFT plant ein Forschungsprojekt, um ein sicheres Referenz-Betriebssystem zu machen, in dem sowohl die Leistungsfähigkeit als auch Sicherheitsaspekte bedacht werden sollen.
CW: Gibt es dahingehend denn schon Vorarbeiten?
Brunnstein: Es gibt eine interne Gruppe, die ist vor anderthalb Monaten eingesetzt worden. Der geht es um die Frage sicherer Software. Das heißt also, Verfahren der allgemeinen Spezifikation von Software und insbesondere Betriebssystemen. Da kommt man dann nach B3 und A1. Auch diese Systeme werden nicht hundertprozentig eingriffssicher sein. Es wird immer Leute geben, die über sehr spezielles Wissen verfügen. Die können einen dann auch immer aufs Kreuz legen. Aber heute kann das ja praktisch jeder. In Zukunft werden es dann eben nur die absoluten Systemspezialisten sein. Aber die Zahl solcher Spezialisten kann man sicher reduzieren.
CW: Was für Losungsvorschläge haben Sie denn, um in Rechenzentren ein akzeptables Sicherheitsniveau zu etablieren?
Brunnstein: Ich würde sagen, virtuelles Betriebssystem vor einem anderen. Weiter würde ich vorschlagen, eine Microvax als Front-end-Rechner und dahinter Unix-Rechner zu installieren. Das wäre sicherlich eine Steigerung der Sicherheit.
CW: Eine Weiterentwicklung von Unix in puncto Sicherheit sehen Sie nicht?
Brunnstein: Ob Unix sich weiterentwickeln läßt, weiß ich nicht. Unix kann ich mir aber oberhalb von B2 überhaupt nicht mehr vorstellen.
CW: Was halten Sie denn von OS/2 als Alternative?
Brunnstein: Ich hin mir über die Entwicklung von OS/2 persönlich auch nicht im klaren, weil einfach die Softwarelücke bei weitem nicht geschlossen ist. OS/2 selber hat allerdings bessere Sicherheitsmechanismen im Mikrokanal. Auch im Betriebssystem selber sind Mechanismen drin, die mehr Sicherheit bieten Aber das ist noch nicht das Gelbe vom Ei. Da wird eine weitere Entwicklung nötig sein. Ich sehe das 0S/2 im Moment einfach als Aufsteigersystem von MS-DOS. Die Unix-Welt ist eine für technische Applikationen und für Entwicklungsapplikationen. Die Problematik OS/2 stellt sich deshalb auch nicht, weil es sich bei Unix und OS/2 um verschiedene Anwendungsbereiche handelt.
CW: Haben Sie noch einen Tip für Unix-Anwender?
Brunnstein: Ich würde jedem Unix-Anwender raten, wenn er nicht nur Entwickler ist, grundsätzlich Entwicklung und Produktion zu trennen. Er sollte bei einem Produktionssystem alles abspecken, was abzuspecken geht. Quasi auf ein Kernsystem, auf dem nur noch ein Programm fährt. Also etwa in der chemischen Industrie Produktionsbeschreibungen für chemische Prozesse. Außerdem muß eine scharfe Zugangskontrolle gewährleistet sein. Das liegt bei Unix heute ein bißchen sehr im argen, weil es kaum ordentliche Audit-Verfahren gibt. Mit großer Sorge sehe ich, daß in einigen Bankapplikationen relativ offene Unix-Systeme eingesetzt
werden. Man sollte die abkapseln. Man sollte auch versuchen, die Netzkommunikation - also so was wie Fernwartung - von vornherein zu vermeiden. Lieber autonome Bereiche schaffen. Wenn dann was passiert, muß natürlich ein Diagnoseprozessor vorhanden sein, der eine entsprechende Warnung abgibt. Man sollte bei Wartungsaufgaben an den Ort hinfahren, anstatt die Möglichkeiten der zugegebenermaßen bequemen Fernwartung zu nutzen. Das
Fernwarten von Unix ist eine hochgradig kritische Angelegenheit.
CW: Unix ist also nicht das Betriebssystem der Zukunft?
Brunnstein: Ich sage Ihnen ganz offen: Ich habe Zweifel, ob Unix sich so ausbreiten wird. Die Inkompatibilitäten der Unix-Versionen sind immer noch nicht behoben. Posix ist immer noch nicht durchgesetzt. Die Geschichte mit OSF ist eine allzu vage Möglichkeit. Die sehr lange Einführungszeit von Unix - Sie müssen ja überlegen, Unix ist über 15 Jahre alt - spricht nicht für ein Betriebssystem. Es kann durchaus sein, daß sich in den nächsten fünf Jahren einige Veränderungen ergeben insbesondere bei den sogenannten verteilten Betriebssystemen. Wo es einzelne Prozessoren und Datenbanken als Server gibt. Das Betriebssystem der Zukunft baut wahrscheinlich ohnehin sehr viel stärker nur noch auf Hardwarebausteinen auf. Die besorgen sich durch Kooperation die Informationen. Diese Konzepte werden von unseren heutigen Betriebssystemen, auch von Workstation-Betriebssystemen, meilenweit entfernt sein.