Kapitel 12 Betriebssysteme & IT-Sicherheit

Transkript

1 Kapitel 12 Betriebssysteme & IT-Sicherheit

2 Motivation für IT-Sicherheit Es gibt wertvolle Informationen, die sorgfältig geschützt werden müssen: Firmengeheimnisse, etc. Eine Hauptaufgabe aller Betriebssysteme: diese Information vor unautorisiertem Zugriff zu schützen Zwei Begriffe: Sicherheit (security) umfassende Problematik Schutz (protection) spezifische BS-Mechanismen dazu Wir werden einige Aspekte der IT-Sicherheit und die dafür eingesetzten Mechanismen und Lösungen in BS betrachten

3 12 Sicherheitsanforderungen Die Computer- und Netzsicherheit bezieht sich auf vier grundlegende Anforderungen: Vertraulichkeit: Nur berechtigte Parteien bekommen einen Lesezugriff auf Informationen (Drucken, Anzeigen, etc.) Integrität: Betriebsmittel dürfen nur von berechtigten Parteien geändert werden (Schreiben, Löschen, Ändern des Status) Verfügbarkeit: Betriebsmittel und Informationen sind für berechtigte Parteien immer verfügbar Authentizität: Computersystem kann die Identität jedes einzelnen Benutzers feststellen

4 Benutzerauthentifikation Leute, die in einem System Ärger verursachen wollen, müssen sich zuerst in das System einloggen können. Da das Wort Hacker auch positiv besetzt ist (Top-Programmierer), werden wir die Computer-Einbrecher als Cracker bezeichnen Das System kann bei Passwort-Eingabe unterschiedlich vorgehen: Windows: ein Stern für jedes eingegebene Zeichen, dem Cracker wird somit die Passwort-Länge verraten Unix ist in dieser Hinsicht sicherer: bei der Passwort-Eingabe wird nichts dargestellt ( Schweigen ist Gold ) Noch eine potentielle Sicherheitslücke: wenn bereits nach der Eingabe des Login-Namens der Versuch vom System abgewiesen wird, so erfährt der Cracker die Ursache des Fehlversuchs Zum Erraten von Passwörtern werden meist Datenbanken mit geläufigen Passwörtern verwendet erstaunlich erfolgreich!

5 Wie Cracker einbrechen Die meisten Cracker rufen den Zielcomputer an und probieren so viele Kombinationen (Login, Passwort), bis sie eine funktionierende finden Das Erraten eines legitimen Login-Namen ist relativ einfach Aber auch das Passwort ist leichter zu erraten als man denkt Empirische Untersuchungen: Vor- und Nachnamen, Städte, Wörterbuch (auch rückwärts) decken mehr als 80% aller Passwörter ab Der Angriff kann über das Internet kommen: einige IP-Adressen durch >nslookup uni muenster.de durch >ping w.x.y.z einen Rechner finden durch >telnet w.x.y.z Login-Passwörter-Paare ausprobieren nach Einbrechen die Passwort-Datei erbeuten: /etc/passwd wobei dieser Prozess leicht zu automatisieren ist Sogar Root-Passwörter sind oft trivial zu erraten: z. B. wurde 1989 in einen Computer des US-Ministeriums für Energie eingebrochen, mithilfe des Login-Passwort-Paares (uucp-uucp), mit dem die Rechner vom Hersteller standardmäßig ausgeliefert wurden 12

6 12 Passwortsicherheit in Unix Unix schützt Passwörter wie folgt: Nach der Eingabe des Passworts wird dieses verschlüsselt durch eine sog. Einwegfunktion, e, bei der der Argumentwert aus dem Funktionswert sehr schwer zu erraten ist Danach wird der errechnete Wert mit dem Eintrag in der Passwortdatei verglichen. Vorteil des Verfahrens: Niemand, nicht einmal der Superuser, kann Passwörter der Benutzer im Klartext nachschlagen Angriff ist trotzdem möglich: der Cracker bereitet im voraus eine Liste verschlüsselter Passwörter und vergleicht sie mit der Passwort-Datei; ein einfaches Shell-Skript kann diesen Prozess automatisieren Erste Abhilfe: Die Passwort-Datei wird unlesbar gemacht und kann nur mit einem speziellen Programm ausgelesen werden. Einträge der Passwort-Datei werden also erst auf Anfrage, d. h. relativ langsam, preisgegeben zusätzlich: die Salt-Methode, s. nächste Folie

7 12 Die Salt-Methode Die Salt-Methode: Abhilfe [Morris & Thompson]: Jedes Passwort wird mit einer n-bit-zufallszahl kombiniert, Salt genannt ( Suppe versalzen ), und die Kombination wird schließlich verschlüsselt. Der Salt-Wert wird ebenfalls in der Passwort-Datei gespeichert: Bobbie, 4238, e(dog4238) Tony, 2918, e(6%%taeff2918) Laura, 6902, e(shakespeare6902) Mark, 1694, e(xab@bwcz1694) Deborah, 1092, e(lordbyron,1092) Der Cracker muss jetzt alle Kombinationen ausprobieren, was 2 n mehr Zeit als ohne Salt braucht; Unix verwendet n = 12

8 Die Salt-Methode: Illustrationsbeispiel 12

9 Passwortsicherheit: Spezielle Methoden Starke Passwörter wählen: nicht zu kurz, Klein- und Grossbuchstaben, mind. eine Zahl oder Sonderzeichen, keine Namen! Sperren, z.b. nach drei fehlgeschlagenen Versuchen Fallen: z. B. für eine einfache Login-Passwort Kombination ein Szenario vorsehen, bei dem das Sicherheits-Personal unterrichtet wird Andere (sicherere) Authentifizierungsmethoden: Challenge-Response: Benutzer wählt eine Funktion, z. B. y = x 2 aus. Beim Einloggen wird der Rechner z.b. 7 senden, worauf der Benutzer mit 49 antworten soll. Smart cards: Biometrische Authentifikation: Fingerabdruck, Stimmerkennung, Netzhautmuster, etc. 12

10 Berühmte Sicherheitslücken Ebenso wie die Industrie ihre Titanic, Challenger oder Concorde hat, gibt es in jedem Betriebssystem bekannte Sicherheitsprobleme Wir geben hier drei bekannte Lücken in Unix an: 1. Der Unix-Dienst lpr zum Drucken einer Datei hat als Option die Datei nach dem Ausdrucken zu löschen. In den ersten Unix-Versionen war es möglich, damit auch die Passwort-Datei zu löschen 2. Einen Link von einer Datei Namens core im Arbeitsverzeichnis auf die Passwortdatei anzulegen, dann einen Core-Dump verursachen somit wird ein Teil der Passwortdatei mit Crackers Information überschrieben 3. Kommando mkdir wurde früher in zwei Schritten ausgeführt. War das System langsam, so konnte sich der Cracker zwischen zwei Schritten einklinken und sich zum Besitzer der Passwortdatei machen. Diese Lücken sind natürlich längst beseitigt!

11 12-1 Entwurfsprinzipien für sichere Systeme Der Entwurf sollte möglichst einfach sein: je mehr Funktionalität und Benutzerfreundlichkeit eingebaut ist, desto höher ist das Risiko Der Systementwurf sollte öffentlich sein; Geheimhaltung ist eine Selbsttäuschung Alle Standardeinstellungen sollten Kein Zugriff lauten Die jeweils aktuellen Berechtigungen sollten immer geprüft werden Jedem Prozess sollten die geringst möglichen Zugriffsrechte zugeordnet werden Der Schutzmechanismus sollte einfach und einheitlich sein und beim Entwurf in die tiefsten Schichten integriert werden. Sicherheit kann nicht in ein unsicheres System nachträglich eingebaut werden Die Sicherheitskonzepte müssen für die Benutzer akzeptabel sein, sonst werden sie nicht beachtet

12 Bedrohungen (bösartige Software) Die Taxonomie bösartiger Programme besteht aus zwei Klassen: Solche, die ein Wirtsprogramm benötigen (Programmfragmente) Eigenständige Programme, die vom Betriebssystem eingeplant, zugeteilt und ausgeführt werden können Es wird auch unterschieden, ob das Programm sich selbst vervielfältigen kann Malware Benötigt Host Programm Unabhängig Hintertüren Logische Trojanisches Bomben Pferd Virus Wurm Zombie Vervielfältigen sich selbst

13 12-1 Virenvermeidung in Betriebssystemen 1. Virus - ein Programm, das sich replizieren kann, indem es sich an den Code von anderen Programmen anhängt 2. Das Betriebssystem sollte eine starke Trennung zwischen Kernel- und User-Modus besitzen und separate Login-Passwörter für jeden Benutzer und den Systemadministrator verwenden: so kann das eingeschlichene Virus nicht die Systemprogramme infizieren 3. Nur originalverpackte Software installieren, die von einem vertrauenswürdigen Hersteller stammt 4. Eine gute Antivirus-Software installieren und regelmäßig updaten 5. Betriebssysteme sollten einfach (ohne Schnickschnack) sein 6. Keine aktiven Inhalte (z. B. keine s mit Word-Dateien, Webseiten mit ActiveX Steuerelementen) verwenden, da sie fremde Programme auf dem Rechner zulassen

14 12-1 Mobiler Code: Sandboxing Während Viren und Würmer i. d. R. unerwünscht von außen kommen, wird fremder Code oft auch absichtlich ausgeführt, z.b. Applets, Agenten. Sandboxing: Beschränkt jedes Applet zur Laufzeit auf einen limitierten Bereich von virtuellen Adressen (Sandbox). Bekanntestes Beispiel: Java Jedem Applet werden zwei Sandboxen zugeteilt: für Code und Daten Jedem Applet wird verboten, zu Code außerhalb der Sandbox zu springen oder Daten von außerhalb zu referenzieren Durch das Verbot von Speicheroperationen in der Code-Sandbox unterbindet man die selbständige Code-Modifikationen des Applets Ein Referenzmonitor prüft jeden Systemaufruf des Programms und entscheidet, ob dieser sicher ist oder nicht

15 12-1 Mobiler Code: Interpretation am Beispiel von Java Webbrowser benutzen den Ansatz, Applets zu interpretieren: dadurch wird dem Applet die tatsächliche Kontrolle über Hardware entzogen Java-Applets werden zuvor in JVM-Bytecode übersetzt und in eine Webseite eingefügt. Beim Herunterladen werden sie dann vom JVM-Interpreter innerhalb des Browsers ausgeführt Anders als beim kompilierten Code, wird der Interpreter jede Anweisung vor ihrer Ausführung überprüfen: Gültigkeit der Adressen, Systemaufrufe, etc. Bei vertrauenswürdigen Applets werden Systemaufrufe ausgeführt, bei Applets von außerhalb wird Sandboxing angewandt (vorige Folie)

16 Java-Sicherheit Java-Programme sollten nach dem Kompilieren in Binärform über das Internet verteilt werden und auf jeder Maschine ablaufen können Sicherheit war von Anfang an ein Teil des Java-Designs Java ist eine typsichere Sprache: der Compiler lehnt jeden Versuch ab, eine Variable in einer mit ihrem Typ nicht vereinbaren Weise zu nutzen So ist z. B. ein Java-Programm ähnlich diesem C-Programm unmöglich: nasty_func(){ char p; p = rand(); // eine Zufallszahl erzeugen und im Zeiger p speichern p = 0; // 0 Byte auf die Adresse in p schreiben und somit den Inhalt } // dieser Speicherzelle überschreiben In C kann dadurch z. B. der Programmcode überschrieben werden In Java sind solche Konstrukte, die Typen vermischen, verboten Java erlaubt keine Manipulation von Referenzen und keine unkontrollierten Typumwandlungen. Alle Arrayzugriffe werden zur Laufzeit überprüft 12-1

17 Java-Sicherheit: Fortsetzung Java-Programme werden in den JVM-Bytecode übersetzt, mit ca. 100 Instruktionstypen (die meisten arbeiten mit einem Typ auf dem Stack) Auch Applets sind JVM-Programme Jedes empfangene Applet wird auf gewisse Eigenschaften überprüft: versucht das Applet, Variablentypen zu vermischen? verletzt es Zugriffsbeschränkungen auf private Klassenelemente? erzeugt es Stack-Überläufe? konvertiert es unerlaubterweise die Variablentypen? und nur bei Einhaltung von Regeln ausgeführt Applets führen auch Systemaufrufe aus, mit denen Java so umgeht: Jedes Applet wird durch Ursprung und Signatur charakterisiert Der Ursprung wird von der Applet-URL angegeben Der Signierer wird durch den verwendeten Private-Key bestimmt Jeder Benutzer legt eine Sicherheitsstrategie fest, als Liste: URL Signierer Objekt Aktion TaxPrep /usr/susan/1040.xls Lesen * /usr/tmp/ Lesen, Schreiben Microsoft /usr/susan/office/ Lesen, Schreiben, Lösche 12-1

18 12.7 Schutzdomänen Ein Computersystem enthält viele Objekte, die geschützt werden müssen, z.b. CPUs, Speichersegmente, Prozesse, Dateien, etc. Eine Domäne (auch Schutzdomäne genannt) ist eine Menge von Paaren (Objekt, Rechte) dieses Konzept wird eingeführt, um verschiedene Schutzmechanismen untersuchen zu können Ein Recht bedeutet die Erlaubnis, bestimmte Operationen auf dem gegebenen Objekt der Domäne auszuführen, z. B.: Jeder Prozess läuft zu jedem Zeitpunkt in einer Schutzdomäne, d. h. es gibt eine Menge von Objekten, auf die er zugreifen kann Prozesse können von Domäne zu Domäne wechseln (z. B. beim Betreten des Kerns im Rahmen eines Systemaufrufs) 12-1

19 12-1 Schutzdomänen und Prozesse In Unix: Die Domäne eines Prozesses wird durch seine Benutzer- (UID) und Gruppennummer (GID) definiert. Für jede (UID, GID)-Kombination ist es möglich eine Liste aller Objekte zu erstellen, auf die zugegriffen werden kann Jeder Unix-Prozess besteht aus zwei Hälften: User-Teil und Kern-Teil. Bei einem Systemaufruf wechselt der Prozess vom User- in den Kern-Teil, daher muss dabei auch ein Domänenwechsel passieren Beispiel wie das System die Übersicht behält : Schutzmatrix (Zeile=Domäne, Spalte=Objekt)

20 Zugriffskontrolllisten (ACL) Die Schutzmatrix wird selten vollständig gespeichert, da sehr groß und dünn besetzt: die meisten Domänen haben keinen Zugriff auf die meisten Objekte. Daher speichert man entweder nur die Zeilen oder nur die Spalten, was zwei recht unterschiedliche Ansätze bedeutet Der ACL-Ansatz (Access Control List): Speichern der Spalten der Schutzmatrix. Zu jedem Objekt wird eine geordnete Zugriffskontrolliste (ACL) geführt, mit allen Domänen, die auf das Objekt zugreifen können Für jede Domäne wird angegeben, wie der Zugriff erfolgen darf Die Zugriffsrechte (R/W/X) werden nach Benutzern (oder Gruppen von Benutzern) und nicht nach Prozessen vergeben 12-2

21 Capabilities Der Capabilities-Ansatz: Speichern der Zeilen der Schutzmatrix Jedem Prozess wird eine Liste von Objekten zugeordnet, auf die er zugreifen kann, mit Angabe möglicher Operationen Mit anderen Worten: jedem Prozess wird seine Domäne zugeordnet, diese Liste wird Capabilities-Liste oder C-Liste genannt C-Listen müssen vor der Manipulation durch Benutzer geschützt werden, dazu gibt es verschiedene Ansätze 12-2

22 12-2 Vergleich: ACLs vs. Capabilities Die beiden Ansätze ergänzen sich zum Teil: Capabilities sind sehr effizient: z. B. ist keine Überprüfung notwendig, wenn ein Prozess eine Datei öffnen will, auf die Capability 3 zeigt; bei einer ACL erfordert dies eine potentiell lange Suche Wenn keine Gruppen unterstützt werden, muss man alle Benutzer in der ACL auflisten, um jedermann Lesezugriff auf eine Datei zu gewähren Capabilities ermöglichen es, Prozesse in ihren Rechten einfach zu beschränken, ACLs hingegen nicht Wird ein Objekt gelöscht und die Capabilities nicht (oder umgekehrt), dann entstehen Probleme. Hingegen leiden ACLs darunter nicht

23 Multilevel-Sicherheit Zwei Arten von Betriebssystemen in Bezug auf wie bestimmt wird, wer auf Daten zugreifen darf: DAC (Discretionary Access Control) - die meisten BS: einzelne Benutzer dürfen selbst bestimmen wer ihre Objekte lesen/schreiben darf MAC (Mandatory Access Control) - in Umfeldern mit stärkerer Sicherheit (Militär etc.): die Sicherheitsregeln dürfen nicht von einzelnen Teilnehmern (Soldaten etc.) eigenständig modifiziert werden

24 Das Bell la Padula Modell Wurde für militärische Sicherheit entwickelt, mit Dokumenten in verschiedenen Sicherheitsstufen (geheim, streng geheim, etc.). 2 Regeln: Die Simple-Security-Regel: ein Prozess kann nur Objekte aus seiner und allen niedrigeren Stufen lesen, z. B.: General darf die Dokumenten eines Leutnants lesen aber nicht umgekehrt! Die *-Regel: Ein Prozess darf nur auf Objekte aus seiner oder höheren Stufen schreiben, z. B. Leutnant darf an General schreiben aber nicht umgekehrt, weil dadurch ein Geheimnis gelüftet werden könnte Wahrt Geheimhaltung (Daten können nicht nach unten weitergegeben werden), aber nicht Integrität (Daten können von unten manipuliert werden) 12-2

25 12-2 Das Biba-Modell Das vorherige Militär -Modell würde in einem Unternehmen folgendes bedeuten: Programmierer (Stufe 3) kann Hausmeister (Stufe 1) über die Unternehmenspläne befragen und dann die Dateien des Präsidenten (Stufe 5) überschreiben, welche die Unternehmensstrategie enthalten Das Biba-Modell ist für die Integrität der Daten entwickelt worden: Die Simple-Integrity-Regel: Ein Prozess darf nur auf Objekte seiner oder niedrigerer Stufe schreiben (no write up). Die Integrity-*-Regel: Ein Prozess kann nur Objekte seiner oder höherer Stufen lesen (no read down) Z. B.: Der Programmierer kann Dateien des Hausmeisters mit Informationen ändern, die er vom Präsidenten bezogen hat, aber nicht umgekehrt

26 12-2 Verteidigung gegen Trojaner Trojanisches Pferd (Trojaner) ist ein (scheinbar) nützliches Programm, das verborgenen Code enthält, der bei Aktivierung Schaden anrichtet, z.b.: Bobs Prozesse und Dateien sind geheim, Alices öffentlich Alices Programm enthält ein trojanisches Pferd, das alle Daten in einem öffentlichen Rucksackdatei ablegt Mögliche Verteidigung: Ein sicheres BS mit zwei Sicherheitsstufen (grau geheim und weiß öffentlich), wobei geheim über öffentlich steht Beim Versuch, die geheime Zeichenkette im (öffentlichen) Rucksack abzulegen wird die *-Eigenschaft verletzt und Referenzmonitor stoppt den Versuch

27 12.9 Verdeckte Kanäle Paradoxon: Es gibt Möglichkeiten, Informationen nach außen zu verraten, auch wenn mathematisch bewiesen wurde, dass dies unmöglich ist! Aufgabe: Server (S) soll keine Infos an den Kollaborator (K) weitergeben. Dazu wird der Server gekapselt: kann nicht direkt mit K kommunizieren Kommunikation ist trotzdem über verdeckte Kommunikationskanäle möglich, z. B.: K überwacht die CPU-Nutzung von S. Wenn S während eines Zeitfensters viel rechnet bedeuted das 1, sonst 0 Andere verdeckte Kanäle: Bestimmte Dateien sperren/freigeben, Seitenfehler produzieren für ein Zeitfenster, das S und K kennen 12-2

28 12-2 Verdeckter Kanal: Steganographie Steganographie = verdecktes Schreiben Beispiel: Informationen in einem Foto verstecken: Links: Originalfoto; Rechts: Foto + Geheime Info (700 KByte) fünf bekannteste Werke von Shakespeare (Hamlet, Macbeth, etc.) So wird s gemacht: Jedes Pixel besteht aus drei 8-Bit-Zahlen. Wenn man nur je 7 Bit zur Farbkodierung benutzt und das niederwertige Bit für die Geheiminfo, dann wird die Änderung für einen Menschen nicht erkennbar! Mehr Details: covered writing Steganographie hat auch Anwendungen mit Sicherheit als Ziel: z. B. Wasser ichen in Web-Bildern (unerlaubtes Wiederverwenden vermeiden)

29 Weiterführende Literatur Tanenbaum A.: Moderne Betriebssysteme, Pearson Studium, 2002, Kapitel 9. Stallings,W.: Betriebssysteme, Pearson Studium, 2003, Kapitel 15. Viel Glück in der Klausur!