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

Berechtigung (capability) für Objekt mit Schnittstelle S = (Verweis, Sicht) (reference, view) auf Objekt Teilschnittstelle von S (Teilmenge aller Operationen von S) (vgl. 5.6.2 für capability-basierte Adressierung) – sprachunabhängig mit durchnumerierten Operationen: Rechte Objektverweis z.B. 24 Bits z.B. 8 Bits bs-6.4.4

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

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

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

 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

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

kommerzielles System, mit hardware capabilities 6.4.4.2 Beispiele IBM AS/400: kommerzielles System, mit hardware capabilities Amoeba (Tanenbaum et al. 1985-95): 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

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.

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

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

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

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

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

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