Über die Sicherheitsrisiken von Unix ist in der Vergangenheit immer wieder geschrieben worden. Spektakuläre Hackerangriffe auf Netzwerke vor allem in den USA nährten die Zweifel daran, ob Computersysteme eigentlich sicher sein können. Betroffen waren allerdings auch andere Betriebssysteme. Bei der Erörterung von Sicherheitsmerkmalen sollte man deshalb zweierlei beachten: Völlige Sicherheit wird es nicht geben. Außerdem stellt der Mensch selbst ein nicht unerhebliches Risikopotential dar. Über Unix als Risikofaktor sprach COMPUTERWOCHE-Redakteur Jan-Bernd Meyer mit Ingo Wieneke, Marketing Director Computer Systems bei AT&T.
CW: Wieviel Schuld bei unsicheren Rechnersystemen muß man denn auf das Konto der Software verbuchen und inwieweit trägt der Anwender Verantwortung?
Wieneke: Die Sicherheit on Computern wird auf zwei Wegen verletzt Sowohl externe als auch interne Personen versuchen, die Sicherheit zu untergraben. Das ist die Kernproblematik. Die Sicherheit ist personenabhängig. Man kann - soviel Sicherheit in einen Computer einbauen wie man will, je mehr Leute die Mechanismen kennen, umso unsicherer wird das System.
CW: AT&T muß ein großes Interesse an der Sicherheit von Unix-Betriebssystemen haben. Was tun Sie, um diese zu realisieren?
Wieneke: Um solche Sicherheiten zu erreichen, arbeitet AT&T mit dem Sicherheitsbüro des amerikanischen Verteidigungsministeriums, dem National Security Center, zusammen. Dieses Büro hat ein Kriterienbuch aufgestellt, das man allgemein als Orange Book kennt. Hierin werden sieben verschiedene Sicherheitsstufen definiert: D, C1, C2, B1, B2, B3 und Al - Al hat quasi noch keiner.
CW: Welchen Standard erfüllt AT&Ts aktuelle Unix-Version?
Wieneke: Wir haben für das AT&T Unix System V/MLS, Multilevel Security, Release 3.1, nach dem Orange Book in Verbindung mit den AT&T-Rechnern 3B2/500 und 3B2/600 die Sicherheitsklasse B1 erreicht. Gleichzeitig sind einige Kriterien der Sicherheitsklasse B2 bereits vorhanden. Wenn im nächsten Jahre Release 4.0 eingeführt wird, dann wird V/MLS auch für dieses Release zur Verfügung stehen. Die UNIX System V Release 4.l ist bereits teilweise auf B3 - also die letzte Stufe vorbereitet.
CW: Nach welchen Kriterien geht man denn beim Sicherheitsbüro des US-Verteidigungsministeriums vor?
Wieneke: Es gibt elf verschiedene Kriterien. Diese befassen sich mit diskretem Zugriff und Sicherheitslabels, mit der zwingenden Zugriffskontrolle, Identifikation und Authentifikation mit Überwachungs- oder Auditfunktionen, dem Objekt-Reuse, und Trusted Pass. Weiter geht es dabei um die Systemintegrietät, also die vertrauliche Verwaltung der Einrichtungen, das Entdecken versteckter Kanäle, also Übertragungskanälen in der Maschine, um die genaue Beschreibung des Entwurfs und die Prüfung des Entwurfs. Letztlich muß die Verwaltung der Konfigurationen klargelegt sein, die gesamten Spezifikationen und es muß eine Dokumentation erstellt werden.
CW: Diese Punkte treffen aber nicht auf alle Sicherheitsklassen zu?
Wieneke: Nein. Im wesentlichen für B1 und aufwärts.
CW: Einige Anforderungen scheinen etwas trivial zu sein.
Wieneke: Ja, wenn man das genau unter die Lupe nimmt, sind da auch triviale Dinge drin. Jedenfalls trifft dies auf Unix zu, weil dort längst vorhanden. Die Identifizierbarkeit von Subjekten oder Gruppen beispielsweise. Etwas Neues bei der vertraulichen Zugriffskontrolle ist, daß es explizit ein Recht gibt, auf etwas keinen Zugriff zu erlauben. Bisher definierte man immer nur Rechte, die besagten, was man machen darf. Kein Recht, etwas zu tun, fiel da nicht drunter. Also ein bißchen von hinten gedacht. Desweiteren verlangt man, daß ACLs, also Access-Control-Lists aufgelistet werden. In diesen ACLs muß man Beziehungen zwischen Subjekten wie Usern und Objekten wie Dateien herstellen können.
CW: Welches sind denn neue Sicherheitsanforderungen?
Wieneke: Relativ neu sind sogenannte Security-Labels. Das sind Etiketten an Objekten und Subjekten, die bestimmten Sicherheitsklassifikationen unterliegen. Diese Security-Labels sind für die Mandatory-Access-Control die Basis beim Einloggen. Bevor ein Benutzer oder auch ein Prozeß in ein Unix-System hineinkommt, muß er Sicherheitskontrollen über sich ergehen lassen. Denn an dieser Stelle ist der Dreh- und Angelpunkt beispielsweise für das Einschleppen von Würmern in vernetzte Rechner.
CW: Wenn ein Prozeß über ein Netz kommt, dann wird an dieser Stelle geprüft, darf er überhaupt in den Rechner rein oder nicht?
Wieneke: Ja, genau so. Eine noch höhere Sicherheit könnte man erreichen mit Standards wie X.400. Da kann der Benutzer oder der Prozeß überhaupt nicht mehr auf die Funktion des Rechners zugreifen. Er kann praktisch nur noch Daten bereitstellen und der Rechner übernimmt die Kontrolle über sich selber. Und genau an der Stelle setzen diese Security-Labels an. Die sind übrigens zwingend ab B1. Diese Security Labels müssen auch beim Exportieren von Daten mit übernommen werden.
CW- Gilt dasselbe auch für externe Gerate?
Wieneke: Ja. Es reicht ja nicht aus, nur einem Betriebssystem Sicherheitslabels zu geben. Also müssen auch etwa Disc-Drives mit solchen Etiketten versehen werden. Es muß gewährleistet sein, daß man das Gerät nicht abhängen kann und woanders dranhängt.
CW: Was versteht man denn unter Identifikation und Authentität?
Wieneke: Einmal ganz banal daß sich der User identifizieren muß beim Log-in. Außerdem muß man den Bezug zwischen Daten, mit denen er gearbeitet hat, und ihm selber rekonstruieren können. Es gibt auch Situationen, wo Paßwörter zwar entschlüsselt, aber trotzdem für die Allgemeinheit nicht lesbar sind. Für diese Situation muß es auch einen Schutz geben.
CW: Auch das Auditing ist ja eine Kontrollmöglichkeit?
Wieneke: Dieser ganze Vorgang muß überwacht werden und das wird über Audit zusammengefaßt. Im Grunde genommen ist das eigentlich ein Accounting-System, wird allgemein aber Audit genannt. Hier werden Ereignisse protokolliert - das Öffnen und Schließen von Dateien etwa. Oder wenn ich ein neues Objekt wie etwa eine Datei anlege, muß das protokolliert werden. Auch Plattenstapel, gemountet werden. Auch das muß man protokollieren.
CW: Sämtliche administrative Funktionen, die ausgeführt werden, müssen auch protokolliert werden?
Wieneke: Genau. Damit erreicht man ein nachvollziehbares Sicherheitssystem. Auch über welche Terminalleitung der Prozeß gestartet wurde, muß man nachvollziehen können.
CW: Audit-Funktionen sind vorgeschrieben ab C2 und aufwärts. Was ist neu an den Audit-Funktionen?
Wieneke: Erst in B3 werden Dinge eingeführt wie das Zufügen von Objekten. Neu ist auch, daß mit diesen Audit-Funktionen der Verwalter, der Sicherheitsverwalter von solchen Systemen mitkontrolliert wird. Wenn ein Administrator an die Maschine geht und neue Platten hinzufügt oder neue Benutzer einrichtet, dann wird auch das protokolliert. Das war bisher nicht der Fall.
CW: Sind eigentlich Programmierer von Systemen auch eine Gefahrenquelle?
Wienecke: Es gibt Programmierer, die haben sich im Speicher einen Bereich angelegt, in dem sie mit Daten arbeiten, die von einem Programm vorher benutzt wurden. Oft waren die Daten noch in diesem Speicher und man konnte sie weiter benutzen. Manche haben wirklich so programmiert. Wenn man dann auf einen anderen Rechner gegangen ist, wo es eben nicht so war, dann sind die Programme in der Regel abgestürzt. Jetzt wird verlangt, daß solche Speicherbereiche garantiert leer sind. Es darf nicht mehr passieren, wenn ein Speicherbereich von zwei verschiedenen Prozessen benutzt wird, daß ein unerlaubter Informationsfluß stattfinden kann. Das heißt, wenn ein Prozeß beendet wird, löscht er auch den entsprechenden Speicherraum. Wenn der nächste Prozeß kommt und benutzt diesen gleichen Speicherraum, dann muß er leer sein. Dieser Object-Reuse gehört zu.
CW: Aber nicht nur Software ist unsicher?
Wienecke: Richtig. Das fällt unter den Punkt des vertraulichen Informationspfades. Ein Sicherheitszertifikat bekommt man nur für ein laufendes System, nicht für den Rechner alleine, nicht für das Betriebssystem alleine, sondern für eine Installation. Und diese Installation umfaßt die ganze Hardware einschließlich aller sicherheitsrelevanter Teile. Das können beispielsweise die Terminalleitungen sein. Wenn diese Teile ausfallen, darf das ganze System nicht mehr weiterarbeiten.
CW: Es darf also beispielsweise niemand eine Karte aus einem Rechner herausnehmen und einfach eine andere dafür einsetzen?
Wienecke: Damit wären ja möglicherweise die Sicherheitsmechanismen umgangen. Auch diese Bestimmung ist neu unter B2.
CW: Wie sieht es denn mit Betriebsystemzugriffen aus?
Wienecke: Wenn ein Benutzer auf die Root zugreift, dann kann er das nur, wenn er bestimmte Rechte hat. Es sei denn, er hat irgendwelche Systemprogramme, die jeder benutzen darf. Normalerweise ist der Rootzugriff ja nur über den Systemadministrator erlaubt. Nur hat sich gezeigt, daß das Recht, auf die komplette Betriebssystembasis zugreifen zu können, eben zu empfindlich ist. Man mußte deshalb noch feiner abgestufte Zugriffsrechte auf das Betriebssystem schaffen. Es muß also sein, daß der Systemadministrator nicht an bestimmte Rootteile kommen darf. Beispielsweise an die Mechanismen, die die Sicherheit testen. Dies soll nur dem System-Sicherheitsadministrator vorbehalten bleiben. Unter dem vertraulichen Verwalten der Gerätschäft versteht man also diese Aufteilung von personellen Funktionen. Auch dies ist neu und gehört zum Level B2.
CW: Es gibt eine Cover-Channel-Analysis. Dabei wird unter anderem geprüft, welche Frequenzen intern der Rechner zur Datenverarbeitung nutzt. Ist das nicht eigentlich nur im militärischen Bereich interessant?
Wienecke: Beileibe nicht. Ein Kollege hat mir erzählt, daß er mit Spielzeugherstellern gesprochen hat, die ein Unix-System brauchen mit dieser Sicherheitsstufe, um ihre nächsten Weihnachtskollektionen zu verheimlichen.
CW: Gibt es denn eine Möglichkeit zu verhindern, daß - wie vergangenes Jahr geschehen - ein Wurmprogramm große Computernetze zum Erliegen bringt?
Wienecke: Ja sicher gibt es das. Das war ja bei AT&T auch gemacht worden. In dem konkreten Fall lag im Mail-System ein Bug vor. Außerdem waren sogenannte Debug-Funktionen nicht aus dem laufenden Programm herausgenommen worden. Bei AT&T waren sie bis auf eine Maschine herausgenommen, die zwar Unix fuhr, aber eben nicht von uns kam. Meiner Ansicht nach gehört es zu einem guten Programmiererstil dazu, zu testen, ob in einem Programm noch Bugs sind. Und wenn Bugs drin sind oder wenn sie bekannt sind, dann müssen sie auch wirklich beseitigt werden. Man muß einfach sicherstellen, daß abgelieferte Programme in Ordnung sind. Das muß von einer anderen Stelle getestet werden. Dann erst kann es freigegeben werden und dann erst darf es eigentlich laufen. Wenn dieser Zyklus nicht eingehalten wird, dann kann man in jede Maschine und jedes System eindringen.