Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Bs-6.4.41 6.4.4 Berechtigungen (Capabilities) Zentrales Prinzip der Systemsicherheit: Restriktive Rechtevergabe: einem Prozess sollen nur diejenigen Zugriffe.

Ähnliche Präsentationen


Präsentation zum Thema: "Bs-6.4.41 6.4.4 Berechtigungen (Capabilities) Zentrales Prinzip der Systemsicherheit: Restriktive Rechtevergabe: einem Prozess sollen nur diejenigen Zugriffe."—  Präsentation transkript:

1 bs 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“)

2 bs 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)5.6.2 – sprachunabhängig mit durchnumerierten Operationen: Objektverweis Rechte z.B. 24 Bits z.B. 8 Bits

3 bs 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)

4 bs Vergleich Schutzstatus Berechtigungen am Modell Zugriffsmatrix (Schutzmatrix, access/protection matrix), z.B. Objekte Subjekte s1 :Segment:Printer d3 :Directory m4 :Mailbox p3 :Process S1write search enter S2write search update delete put p3 read delete putblock S4 read write block unblock put get wakeup Matrixelement = Menge von Rechten

5 bs 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

6 bs Fälschungssichere Implementierung Verschiedene Alternativen:  Kryptographische Versiegelung, Speicherung wie normale Daten: Objektverweis PrüfcodeRechte f geheime „Einbahnfunktion“

7 bs  Speicherung in verschattetem Bereich eines Segments, Identifizierung mit „negativ interpretierten“ Adressen:  Speicherung in prozessspezifischer Berechtigungsliste (capability list) beim Betriebssystem, durchnumeriert

8 bs Eignung der drei Alternativen für Rechte-Weitergabe über Vererbung an Kindprozess Interprozess-gemeinsames kommunikation Segment  –  –  (  )  – – 

9 bs 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 ?

10 Unix-Kanalliste (6.1.2  ) ähnelt einer Berechtigungsliste:6.1.2 Einträge verweisen auf Kanäle (Iteratoren); allerdings befinden sich die Rechte nicht bei den Verweisen, sondern in den Iteratoren: pos Dateitabelle RW R Z.B. wird write(2,..) als unzulässig erkannt, ohne dass der Schutzstatus der Datei befragt werden muss.

11 bs Berechtigung für Kanal-Objekt erzeugen: open kopieren: dup, dup2 löschen: close

12 bs 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,..)

13 bs Benutzungder Datei im Direktzugriff (ohne Kanal): read(fileCap, from, n, buffer) write(fileCap, to, n, buffer) Benennungerfordert Besitz einer Berechtigung für ein Verzeichnis: enter(dirCap, name, fileCap)

14 bs 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.

15 bs 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“)

16 bs Lösung in Amoeba: Verzeichnisse (für Dateien und andere Objekte!) enthalten Einträge folgender Art (vereinfacht): namereferenceownergroupothers Rechte ! Unterschiedliche Rechte an dem Objekt „name“: für Eigner des Verzeichnisses, Eignergruppe und andere ! lookup liefert Berechtigung reference...


Herunterladen ppt "Bs-6.4.41 6.4.4 Berechtigungen (Capabilities) Zentrales Prinzip der Systemsicherheit: Restriktive Rechtevergabe: einem Prozess sollen nur diejenigen Zugriffe."

Ähnliche Präsentationen


Google-Anzeigen