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
1
Berechtigung (capability) für Objekt mit Schnittstelle S =
(Verweis, Sicht)
auf Objekt
(reference, view)
Teilschnittstelle von S
(Teilmenge aller Operationen von S)
(vgl. 5.6.2 für capability-basierte Adressierung)
– sprachunabhängig mit durchnumerierten Operationen:
bs-6.4.4
Objektverweis
Rechte
z.B. 24 Bits
z.B. 8 Bits
2
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
3
Vergleich Schutzstatus  Berechtigungen am Modell
Zugriffsmatrix (Schutzmatrix, access/protection matrix), z.B.
Objekte
Subjekte
s1
:Segment
S1
S2
bs-6.4.4
p3
read
delete
S4
read
write
d3
m4
p3
:Printer
:Directory
:Mailbox
:Process
write
search
enter
write
search
update
delete
write
block
unblock
put
put
block
put
get
wakeup
Matrixelement = Menge von Rechten
4
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
5
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
6
 Speicherung in verschattetem Bereich eines Segments,
Identifizierung mit „negativ interpretierten“ Adressen:
..
.
-2
-1
0
1
2
3
..
.
 Speicherung in prozessspezifischer Berechtigungsliste
(capability list) beim Betriebssystem, durchnumeriert
bs-6.4.4
7
Eignung der drei Alternativen für
Rechte-Weitergabe über
Interprozesskommunikation
Vererbung an Kindprozess
gemeinsames
Segment



–

–

()

–
–

bs-6.4.4
8
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
9
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:
0
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
bs-6.4.4
erzeugen:
open
kopieren:
dup, dup2
löschen:
close
11
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,..)
bs-6.4.4
12
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
13
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
14
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
15
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
bs-6.4.4
reference
...
16

bs-6.4.4