Präsentation herunterladen
1
6.4.4 Berechtigungen (Capabilities)
Zentrales Prinzip der Systemsicherheit: Restriktive Rechtevergabe: einem Prozess sollen nur diejenigen Zugriffe erlaubt sein, die gemäß Spezifikation des ausgeführten Programms unverzichtbar sind (principle of least privilege, need-to-know principle) Dieses Prinzip wird durch den Zugriffsschutz mittels Autorisierung/Schutzstatus verletzt, z.B. kann ein Editor durch seinen Benutzer nicht daran gehindert werden, heimlich Daten in eine fremde Datei zu kopieren („Trojanisches Pferd“) bs-6.4.4
2
Berechtigung (capability) für Objekt mit Schnittstelle S =
(Verweis, Sicht) (reference, view) auf Objekt Teilschnittstelle von S (Teilmenge aller Operationen von S) (vgl für capability-basierte Adressierung) – sprachunabhängig mit durchnumerierten Operationen: Rechte Objektverweis z.B. 24 Bits z.B. 8 Bits bs-6.4.4
3
Konzeptionell ist eine Berechtigung ein
abstrakter Datenwert vom Typ Capability, also nur durch bestimmte Operationen manipulierbar („fälschungssicher“, unforgeable): Erzeugen (bei Objekterzeugung) Kopieren/Weitergabe Weitergabe mit Rechte-Einschränkung (restriction) Weitergabe mit Rechte-Erweiterung (amplification) Entzug (revocation) Löschen (durch Überschreiben, z.B. mit null-Berechtigung) bs-6.4.4
4
Vergleich Schutzstatus Berechtigungen am Modell
Zugriffsmatrix (Schutzmatrix, access/protection matrix), z.B. Objekte Subjekte s1 :Segment :Printer d3 :Directory m4 :Mailbox p3 :Process S1 write search enter S2 update delete put read block S4 unblock get wakeup bs-6.4.4 Matrixelement = Menge von Rechten
5
Schutzstatus = Spalte einer Matrix, gespeichert beim Objekt,
Vergleich: Schutzstatus = Spalte einer Matrix, gespeichert beim Objekt, typischerweise mit Aggregierung von Subjekten (Gruppen u.ä.); Berechtigungen = Zeile einer Matrix, gespeichert beim Subjekt; Weitergabe von Rechten besser möglich als mit Schutzstatus Zurücknahme von Rechten schlechter möglich als mit Schutzstatus bs-6.4.4
6
6.4.4.1 Fälschungssichere Implementierung
Verschiedene Alternativen: Kryptographische Versiegelung, Speicherung wie normale Daten: Objektverweis Rechte Prüfcode f geheime „Einbahnfunktion“ bs-6.4.4
7
Speicherung in verschattetem Bereich eines Segments,
Identifizierung mit „negativ interpretierten“ Adressen: . -2 -1 1 2 3 4. Möglichkeit – HW: tagged architecture (z.B. IBM AS/400). Speicherung in prozessspezifischer Berechtigungsliste (capability list) beim Betriebssystem, durchnumeriert bs-6.4.4
8
Eignung der drei Alternativen für
Rechte-Weitergabe über Vererbung an Kindprozess Interprozess- gemeinsames kommunikation Segment – – () – – bs-6.4.4
9
kommerzielles System, mit hardware capabilities
Beispiele IBM AS/400: kommerzielles System, mit hardware capabilities Amoeba (Tanenbaum et al ): verteiltes Betriebssystem mit kryptographisch gesicherten Berechtigungen MS Windows: Benutzerprogramm erhält „handles“ genannte Berechtigungen zum Zugriff auf Systemobjekte wie z.B. Prozesse, Semaphore, Kanäle etc. Unix ? bs-6.4.4
10
Unix-Kanalliste (6.1.2) ähnelt einer Berechtigungsliste:
Einträge verweisen auf Kanäle (Iteratoren); allerdings befinden sich die Rechte nicht bei den Verweisen, sondern in den Iteratoren: 1 2 3 4 5 6 7 pos RW Dateitabelle pos R Z.B. wird write(2,..) als unzulässig erkannt, ohne dass der Schutzstatus der Datei befragt werden muss.
11
Berechtigung für Kanal-Objekt
erzeugen: open kopieren: dup, dup2 löschen: close bs-6.4.4
12
6.4.4.3 Capability-basierter Dateischutz
Implementierung erlaubt, in Dateiverzeichnissen Berechtigungen statt interner Dateinummern unterzubringen ( kein Schutzstatus bei den Dateien!) Dateierzeugung erfordert Besitz einer entsprechenden Berechtigung für das Dateisystem: fileCap = create(fileServerCap,..) Rechte von fileCap: entweder alle oder Parameter von create. bs-6.4.4
13
Benennung erfordert Besitz einer Berechtigung für ein Verzeichnis:
enter(dirCap, name, fileCap) Benutzung der Datei im Direktzugriff (ohne Kanal): read(fileCap, from, n, buffer) write(fileCap, to, n, buffer) bs-6.4.4
14
Beachte: Berechtigungen können wie normale Daten
- als Konstanten in Programmen auftauchen, - als Parameter an Programme übergeben werden, - als Nachrichten an Prozesse geschickt werden, - etc. Folgerung 1: Unix-Konzept „setuid-Programm“ ist überflüssig: Zu den Konstanten des Programms gehören Berechtigungen für die zugehörigen Dateien. bs-6.4.4
15
Folgerung 2: Prozess kann nur diejenigen Dateien
ansprechen (und mit denjenigen Operationen), für die er Berechtigungen erhalten hat – d.h. dem Prinzip der restriktiven Rechtevergabe wird Genüge getan. Aber: wie können Berechtigungen weit gestreut werden? (z.B. „alle Welt soll mein schönes Programm benutzen können“) bs-6.4.4
16
Verzeichnisse (für Dateien und andere Objekte!) enthalten
Lösung in Amoeba: Verzeichnisse (für Dateien und andere Objekte!) enthalten Einträge folgender Art (vereinfacht): name reference owner group others Rechte ! Unterschiedliche Rechte an dem Objekt „name“: für Eigner des Verzeichnisses, Eignergruppe und andere ! lookup liefert Berechtigung reference . . . bs-6.4.4
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.