Sicherheit in Betriebssystemen

Transcrição

Sicherheit in Betriebssystemen
Winfried E. Kühnhauser und Jochen Liedtke
GMD – Forschungszentrum Informationstechnik
Schloss Birlinghoven
D-53754 Sankt Augustin
email: [winfried.kuehnhauser|jochen.liedtke]@gmd.de
Abstract
Heutige Anwendungen informationstechnischer Systeme umfassen ein breites Spektrum, welches insbesondere auch sensible Bereiche wie Klinik-Informationssysteme,
juristische Dokumentenverarbeitung oder Anwendungen in der Finanzwirtschaft umfaßt. Da der Einsatz dieser Systeme mittelfristig nur dann gesellschaftliche Akzeptanz
finden wird, wenn Vertrauen in ihre Sicherheit hergestellt werden kann, rücken in zunehmenden Maße Sicherheitsaspekte in der Vordergrund.
Eine zentrale Stellung in der Entwicklung sicherer Anwendungssysteme nehmen Sicherheitspolitiken ein – Regelwerke, die den Umgang mit sensitiven Informationen
festlegen. Das breite Spektrum der Anwendungssysteme erfordert dann ebenfalls in ein
breites Spektrum anwendungsspezifischer Sicherheitspolitiken, auf das die Paradigmen
heutiger Systemplattformen nur unzulänglich anwendbar sind.
Dieser Beitrag stellt ein Objektmodell für anwendungsspezifischer Sicherheitspolitiken
vor und leitet aus den Anforderungen des Modells Basiskonzepte in µ-Kernen zu seiner
Implementierung ab.
1
Sicherheit
In der Entwicklung informationstechnischer Systeme zeichnet sich ein deutlicher Trend
hin zu offenen verteilten Systemarchitekturen ab, die ihrerseits eine Fülle neuer Anwendungsgebiete erschließen. Mit neuen Technologien ist stets auch die Entstehung neuer
Risiken verbunden, die im Bereich der Computersicherheit in sensiblen Anwendungen wie Klinik-Informationssysteme, juristischer Dokumentenverarbeitung oder Anwendungen in der Finanzwirtschaft besonders deutlich sind. Der Einsatz informationstechnischer Systeme wird hier nur dann gesellschaftliche Akzeptanz finden, wenn es
gelingt, Vertrauen in die Sicherheit dieser Systeme herzustellen.
Der Begriff ,,Sicherheit” wird im Zusammenhang mit Computersystemen zuweilen unterschiedlich interpretiert. Eine Ursache liegt in der Ermangelung eines allgemein akzeptierten präzisen deutschen Äquivalents der beiden englischen Begriffe security und
safety: für beide Begriffe wird im Deutschen das Wort Sicherheit verwendet. Wenn
auch im Englischen eine scharfe Trennung zwischen diesen beiden Begriffen nur schwer
zu ziehen ist, so bestehen jedoch einige grundsätzliche Unterschiede. Dieser Artikel hat
1
Kühnhauser, Liedtke: Sicherheit in Betriebssystemen. GMD Tech. Report 959
2
Sicherheit im Sinne von security zum Thema: den Umgang mit zielgerichteter und mit
Intelligenz betriebener (im Gegensatz zu zufälliger oder durch Fehler hervorgerufener)
Verletzung der Integrität, der Vertraulichkeit oder der Verfügbarkeit von Informationen
in einem Computersystem.
Ein Schlüsselbegriff bei der Konzeption sicherer Anwendungssysteme ist die Sicherheitspolitik. Die auch unter dem Namen Orange Book bekannten Trusted Computer System Evaluation Criteria (TCSEC)[12] definieren eine Sicherheitspolitik als ,,Sammlung
von Gesetzen, Regeln und Praktiken, die den Umgang, den Schutz und die Verbreitung
von sensitiven Informationen in einer Organisation festlegen”. Eine Sicherheitspolitik
bestimmt somit die Ziele und Wege, mittels derer eine Organisation ihre spezifischen
Sicherheitsanforderungen umzusetzen sucht. In einer Reduzierung des Begriffs auf informationstechnische Systeme spricht man dann von einer technischen Sicherheitspolitik und meint damit die Software- (teils auch die Hardware-) Komponenten eines
informationstechnischen Systems, die die Sicherheitspolitik innerhalb des Systems implementieren. Letztere reduzierte Sicht wird in diesem Beitrag angenommen.
Die ökonomische, soziale und technische Entwicklung der letzten Dekade konfrontiert
uns mit Sicherheitsanforderungen, die immer individuellere und komplexere Sicherheitspolitiken hervorbringen, mit der Multilevel Security Policy [3] als dem ersten Exemplar einer stetig wachsenden Vielfalt [6, 11, 5, 26]. Auf diese Vielfalt sind heutige
Systemplattformen äußerst unzulänglich vorbereitet. Viele der heute bekannten Architekturprinzipien sicherer Systeme zielen traditionell auf die Unterstützung einer
einzigen, fest in ein Betriebssystem integrierten Sicherheitspolitik ab, die sich dar überhinaus lediglich mit dem Aspekt der Zugriffssteuerung befaßt.
Dieser Beitrag beschreibt ein Konzept zur Integration von Anwendungssystemen mit
benutzerdefinierten anwendungsspezifische Sicherheitspolitiken und beschreibt minimale zur Implementierung der Politiken notwendige Betriebssystem – Basiskonzepte.
2
Sicherheitspolitiken
Die Sicherheit eines Systems hängt entscheidend von der Sorgfalt ab, mit der Sicherheitspolitiken enwickelt und implementiert werden. Um hier hohen Qualitätsanforderungen gerecht zu werden, erfolgt die präzise Formulierung einer Sicherheitspolitik
häufig in einem Sicherheitsmodell, das dann die Ausgangsbasis einer Implementierung
bildet. Sicherheitsmodelle sind in der Regel formal; sie werden zumeist unter Verwendung algebraischer Strukturen [3, 11, 5] spezifiziert und bilden hierdurch eine Basis f ür
den Nachweis von Modelleigenschaften [21].
In den heutigen Umfeldern großer verteilter Systeme kann aufgrund der Autonomie
der einzelnen Systeme in der Regel nicht auf eine einzige systemweite Sicherheitspolitik einigen. Eine Sicherheitspolitik kontrolliert daher stets nur einen Ausschnitt des
Gesamtsystems, die ihr zugeordnete Sicherheitsdomäne. Zur Beschreibung von Sicherheitsdomänen werden sowohl Mengen von Rechnersystemen (,,alle zu einer Organisation gehörenden Systeme”) als auch logische Objektmengen (,,alle zu einer Applikation
gehörenden Prozesse, Server, Dokumente etc.”) verwendet.
Basieren die Regeln einer Sicherheitspolitik auf allgemeinen Subjekt/Objektattributen
(z.B. auf einer Klassifikation der Vertrauenswürdigkeit von zugreifenden Subjekten
3
und der Vertraulichkeit von Objekten, auf die zugegriffen wird), so nennt man diese
Politik mandatorisch. Basieren die Regeln dagegen ausschließlich auf Identitäten von
Subjekten und Objekten, so nennt man eine Politik diskret. Ein augenfälliger Unterschied zwischen diesen Politik-Klassen liegt darin, daß mandatorische Politiken selbst
gegenüber privilegierten Eigentümern von Objekten ihre Regeln durchsetzen können.
Das folgende Beispiel erläutert diese Begriffe noch einmal anschaulich.
Das Szenarium des Beispiels ist ein Übungskurs an einer Universität, in dem Studenten
Hausaufgaben in Form elektronischer Dokumente in einem gegebenen Verzeichnis ablegen sollen. Dieses Verzeichnis enthält ebenfalls eine Musterlösung der Hausaufgaben,
die ein Student allerdings erst dann einsehen darf, wenn er seine eigenen Hausaufgaben in dem Verzeichnis hinterlegt hat. Ebenfalls darf er keine neue Version seiner
Hausaufgabe mehr nachreichen, nachdem er erst einmal die Musterlösung eingesehen
hat.
Eine Sicherheitspolitik für dieses Szenarium besteht also aus den folgenden zwei einfachen Regeln:
Regel 1: Mensch darf Hausaufgaben solange hinterlegen, bis Mensch einmal auf die
Musterlösung zugegriffen hat
Regel 2: Mensch darf die Musterlösung erst dann einsehen, wenn Mensch eine eigene
Hausaufgabe hinterlegt hat.
Diese informellen Regeln können nun beispielsweise durch das folgende formale Sicherheitsmodell präzisiert werden. Das Modell ist eine algebraische Struktur, bestehend
aus zwei Typen, zwei Prädikaten und zwei Operationen. Typen des Modells sind die
Menge S der Studenten und die Menge BOOL = {true, f alse}. Wir definieren dann
zwei Prädikate auf S:
HatAbgegeben : S → BOOL
HatM usterlösung : S → BOOL
Wir definieren weiterhin zwei Operationen:
Abgaberegel(s)
⇔
M usterlösungsregel(s) ⇔
¬HatM usterlösung(s)
HatAbgegeben(s)
HatAbgegeben(s)
HatM usterlösung(s)
Mit initial HatAbgegeben(s) = f alse für alle s ∈ S und HatM usterlösung(s) = f alse
für alle s ∈ S kann gezeigt werden, daß lediglich Operationsfolgen des Musters
Abgaberegel; Abgaberegel ∗ ; M usterlösungsregel ∗
für ein gegebenes s möglich sind: einerseits muß der Musterlösungsregel mindestens eine Abgabe vorausgehen; andererseits ist die Musterlösungsregel erst einmal ausgeführt,
kann durch keine Operation die Vorbedingung der Abgaberegel wieder hergestellt werden, und die Äquivalenz von Sicherheitspolitik und Modell ist damit glaubhaft.
Die Domäne unserer Beispielpolitik besteht lediglich aus dem Kurs-Verzeichnis. Zur
Durchsetzung der Politik ist es ausreichend, die Ablage und Abholung von Dokumenten
aus diesem Verzeichnis zu kontrollieren.
4
Da die Regeln der Politik unabhängig vom Eigentümer des Verzeichnisses sind und
ausschließlich auf der Zugriffshistorie der Studenten beruhen, handelt es sich um eine
mandatorische Politik: kein Student kann sie umgehen, selbst dann nicht, wenn er der
Eigentümer des Kurs-Verzeichnisses ist.
Dieses Beispiel illustriert die Begriffe Sicherheitspolitik, Sicherheitmodell und Sicherheitsdomäne. Im weiteren Verlauf des Beitrages wird betont, daß die Durchsetzung
selbst einer so einfachen Sicherheitspolitik in einer offenen Umgebung noch sehr viel
mehr Aspekte als lediglich das formale Aufschreiben der Politik enthält: Repräsentation der Politik auf einer Systemplattform, Kooperation mit anderen Sicherheitpolitiken
(beispielsweise zur Authentikation der handelnden Menschen und beteiligten Systeme),
Einsatz von Sicherheitsmechanismen.
3
Das Custodian-Modell
Das Custodian-Modell ist ein Objektmodell für anwendungsspezifische Sicherheitspolitiken. Es liefert ein Paradigma für die Repräsentation einer Sicherheitspolitik auf einer
Systemplattform. Seine funktionalen und nichtfunktionalen Eigenschaften implementieren die impliziten und expliziten Annahmen des Sicherheitsmodells (z.B. Manipulationssicherheit der Implementierung) [20].
Eine Sicherheitspolitik wird im Custodian-Modell repräsentiert als eine Ansammlung
von Daten und Algorithmen. Custodians kapseln diese Ansammlung und schützen
so die Integrität der Politik. Ein Custodian besitzt eine Methodenaufrufschnittstelle,
die der enthaltenen Politik die wohldefinierte Kommunikation mit ihrer Umgebung
erlaubt. Custodians sind persistent und können so die Grundlage für das Gedächtnis
einer Politik liefern. Custodians besitzen einen Typ, um Politikwiederverwendbarkeit
durch Subtyping und Komposition zu unterstützen.
Eine Politik wird einem Anwendungssystem zugeordnet, indem den Bausteinen des
Anwendungssystems – Prozesse und Dateien in Unix, Klienten und Server in der OSF
DCE – ein Custodian assoziiert wird. Alle Objekte, die demselben Custodian zugeordnet sind, bilden die Politikdomäne. In diesem Sinn wird die Sicherheitspolitik zum
Attribut eines jeden Applikationsobjekts.
Die Applikationsobjekte einer Domäne sind nicht länger frei in ihrer Kommunikation.
Jegliche Kommunikation resultiert in einer Umleitung über den assoziierten Custodian
und führt zum Aufruf einer Politikoperation. Die Zuordnung von Politikoperationen
und Objektoperationen ist abhängig von der Granularität der speziellen Politik: eine
Zugriffssteuerungspolitik etwa könnte lediglich eine einzige Operation (z.B. CheckAccess(Subject,Object) definieren. Unsere obige Beispielpolitik dagegen definiert eine eigene Politikoperation für jede der beiden existierenden Objektoperationen.
Zur Durchsetzung auf einer Systemplattform stellt das Custodian-Modell einige Anforderungen an die zugrundeliegende Infrastruktur. Es benötigt
• ein Kapselungsschema zur Konstruktion von Einheiten bestehend aus einer Sammlung von Algorithmen und Daten
• einen Kommunikationsmechanismus zur Konstruktion eines Methodenaufrufmechanismusses
5
• eine Möglichkeit zur Erzielung von Persistenz solcher Einheiten
• eine Möglichkeit zur Assoziation von Custodians zu Applikationsobjekten mit
der Wirkung der Umleitung der regulären Objektkommunikation.
Die präzise Definition der Kapselungs-, Persistenz- und Kommunikationseigenschaften
ergibt sich aus der Integration des Custodian-Modells in eine konkrete Systemplattform. Obwohl dadurch manchmal Einschränkungen durch die Unzulänglichkeiten gegebener Plattformen notwendig sind, gewinnen wir doch eine leichtere Integrierbarkeit
des Modells auf einer breiteren Plattformbasis. Dagegen sind auf jeder Plattform Custodians normale Objekte des Objektmodells der Betriebssystemoberfläche. Custodians in
der BirliX-Sicherheitsarchitektur sindäre benutzerdefinierte abstrakte Datentypen [19];
auf einer Unix-Plattform sind Custodians Unix-Prozesse (wobei das Politikgedächtnis
mittels Dateien implementiert ist), und in einer DCE-Umgebung sind Custodians als
DCE-Server implementiert [25].
4
Probleme monolithischer Systeme
Jedes klassische monolithische Betriebssystem hat normalerweise eine spezielle Sicherheitspolitik integriert. Für die Realisierung der benötigten anwendungsspezifischen Politiken sind diese integrierten Politiken aber in der Regel unzulänglich oder nicht flexibel
genug.
Betrachten wir beispielsweise eine Realisierung der Hausaufgabenpolitik in Unix. Gegeben sei eine Datenbank für Musterlösung und Hausaufgaben, realisiert als Server,
d.h. Userid + Dämon. Weiterhin sei jeder Student durch eine Userid realisiert verfüge
über ein Klientenprogramm, das mittels RPC über den Server auf die Datenbank zugreift. Zur Realisierung der Sicherheitspolitik müssen wir den benötigten Custodian
in den vorhandenen Server integrieren, d.h. die Programmierung der Applikationssoftware ändern. Es gibt keine Möglichkeit, den Datenbankserver ohne Änderung durch
Mechanismen des Betriebssystems zu kapseln.
• Erstellung und Änderung von Custodians wäre teuer. Wenn der Server nicht
im Quellcode vorliegt oder aus Sicherheitsgründen nicht modifiziert werden darf,
wäre die Integration von Custodians sogar unmöglich.
• Der gesamte Unix-Kern (mehr als 200.000 Zeilen Code) gehörte zur Trusted Computing Base, müßte also validiert werden und bleiben.
• Jeder Objektzugriff müßte über den in Unix relativ teuer realisierten RPC erfolgen. Speziell für feingranularen Zugriff brauchte man einen schnellen RPC
und/oder Möglichkeiten, Dateien unter Server- und Custodian-Kontrolle in die
Klienten-Adreßräume zu mappen.
Im allgemeinen schreiben monolithische Betriebssysteme eine spezielle und relativ hohe Abstraktionsschicht fest, z.B. Dateien, Prozesse, Pipes und Sockets. Sicherheitspolitiken mit breiten Anwenderspektren erforden aber Modifikationen dieser Schicht,
6
konkurrierende Politiken u.U. sogar einander widersprechende Modifikationen. Deshalb können in monolithischen Systemen flexible und koexistierende oder gar konkurrierende Sicherheitspolitiken in der Regel nur mit hohem Aufwand, häufig sogar nur
eingeschränkt, implementiert werden und leiden unter strukturell bedingter Ineffizienz.
5
Basiskonzepte in µ-Kernen
Verwendet man einen µ-Kern und ergänzt ihn beispielsweise durch einen Unix-Server
[10, 17, 18, 2], sollten die oben erwähnten Nachteile gänzlich verschwinden oder aber
wenigstens stark abgeschwächt werden. Voraussetzung ist allerdings eine effiziente µKern-Implementierung. Ältere (und einige neuere) Erfahrungen [13, 4, 29, 9] und besonders [8] ließen allerdings vermuten, daß µ-Kerne prinzipiell deutlich langsamer sind
als monolithische Systeme. Neuere Forschungen [7, 14, 15, 23] beweisen aber, daß µKerne sehr effizient sein können. Wie wir in [24] gezeigt haben, sind die Ineffizienzen
früherer Ansätze im wesentlichen durch (a) falsche Abstraktionen, (b) unzureichende
Implementierung und (c) Prozessorunabhängigkeit1 bedingt.
Das entscheidende Kriterium beim Entwurf einer µ-Kern-Schnittstelle ist Sicherheit.
Ein Konzept sollte dann und nur dann im Kern toleriert werden, wenn eine Realisierung
außerhalb des Kerns die Implementierung sicherer Subsysteme unmöglich machte.
5.1
Optionale Sicherheit (to def)
Die wesentlichen Bedingungen für die Realisierung optionaler Sicherheit sind:
• Das Autonomieprinzip: Man muß ein Subsystem so implementieren können, daß
es von keinem anderen Subsystem gestört oder korrumpiert werden kann.
• Das Integritätsprinzip: Subsystem S1 muß sich auf Garantien von S2 verlassen
können, d.h. beide Subsysteme müssen miteinander kommunizieren können, ohne
daß ein drittes Subsystem diese Kommunikation stören, fälschen oder abhören
kann. Rückbezug auf die drei Security-Prinzipen.
Basiskonzepte zur Realisierung dieser Prinzipien sind Adreßräume, Threads (incl. Kommunikation) und zeiteindeutige Identifikatoren.
5.1.1
Adreßräume
Auf der Hardware-Ebene ist ein Adreßraum eine Abbildung, die jeder virtuellen Seite
eine physische Kachel im Realspeicher zuordnet oder sie als ‘nicht zugreifbar’ markiert. (Zur Vereinfachung vernachlässigen wir Accessattribute wie ‘read-only’ oder
‘read/write’.) Die Abbildung wird mit Hilfe von TLB-Hardware und Adreßumsetztabellen (Page Tables) realisiert.
1
Bei µ-Kernen ist Portabilität wirklich etwas Negatives: sie kostet Effizienz und spart jedoch wenig, da eine Neuimplementierung nicht viel teurer als eine Portierung und die Zahl der interessanten
Prozessorfamilien relativ klein ist.
7
Der µ-Kern, die allen Subsystemen gemeinsame mandatorische Schicht, muß die HardwareAdreßräume durch ein eigenes Adreßraumkonzept überlagern. Um überhaupt Schutz
zu ermöglichen, muß das Adreßraumkonzept gezähmt werden, aber mit minimalen Restriktionen. Möglichst viele alternative und konkurrierende Schutzkonzepte sollen darauf basierend implementiert werden können. Außerdem sollte das µ-Kern-Adreßraumkonzept
einfach sein und dem Hardware-Konzept ähneln.
Die grundlegende Idee dafür ist die rekursive Konstruktion und Verwaltung der Adreßräume
auf Benutzer-/Server-Ebene. Der µ-Kern stellt dafür genau drei Operationen bereit:
map, flush und grant (Beschreibung siehe [24]). Damit können mehr oder minder systemnahe Server und Anwendersysteme Seiten des eigenen Adreßraums ihren Klienten
zur Verfügung stellen. Ausgehend von einem vorgegebenen Ur-Adreßraum, dem Realspeicher, werden Speicherverwaltung(en), Pager u.ä. vollständig außerhalb des µ-Kerns
realisiert (siehe Abb. 1).
Applikation
Applikation
Applikation
Applikation
Pager 4
P
PP
Pager 3
PP
Pager 1
@
@
Pager 2
@
@
Realspeicher
Abbildung 1: Adreßräume.
5.1.2
Threads und IPC
Ein Thread ist eine innerhalb eines Adreßraums ablaufende Aktivität. Typischerweise
hat jeder Thread einen eigenen Stack und virtuellen Registersatz. Die Assoziation zum
Adreßraum kann dynamisch oder fest sein. Sie darf allerdings nur unter Kontrolle des µKerns verändert werden, da sonst fremde Adreßräume gelesen und korrumpiert werden
könnten. Dieses Sicherheitsargument ist der entscheidende Grund, das Thread-Konzept
im µ-Kern zu realisieren. Alle anderen Gründe, z.B. Preemption, sind demgegenüber
sekundär.
Da Kommunikation über Adreßraumgrenzen aus denselben Sicherheitsgründen nicht
unkontrolliert geschehen darf, wird Inter-Prozeß-Kommunikation (IPC) eine weitere
Aufgabe des Kerns. Klassische (und funktional äquivalente) Methoden sind Botschaftstransfer oder Remote Procedure Call (RPC). In beiden Fällen wird IPC durch eine
Kooperationsvoraussetzung zwischen den beteiligten Partnern kontrolliert. Beim Botschaftstransfer kann der Sender dem Empfänger nur mit dessen Zustimmung eine Botschaft zustellen, und dem Empfänger bleiben Prüfung und Interpretation der Botschaft
überlassen. Beim RPC kann der Aufrufer nur solche Prozeduren aufrufen, die ihm der
Aufgerufene zugänglich macht. Außerdem sind Code und Daten der aufgerufenen Prozedur für den Aufrufer weder sichtbar noch modifizierbar.
5.1.3
8
Eindeutige Identifikatoren
Zusammen mit dem Adreßraumkonzept bildet IPC die Basis des Autonomieprinzips.
Das Integritätsprinzip erfordert neben Abhör- und Verfälschungssicherheit, daß das Ziel
vom Sender eindeutig spezifiziert werden und daß der Empfänger die Quelle korrekt
bestimmen kann.
Die Kosten lokaler Interprozeßkommunikation liegen im Bereich von 1 bis 10 µs, jedenfalls bei effizienten µ-Kernen. Kryptografische Authentisierung [27, 16] pro IPCVorgang scheidet aus Effizienzgründen aus. Einfache Capabilities [28] können zwar
ohne kryptografischen Aufwand überprüft werden, sind aber zu unsicher, weil sie unkontrolliert dupliziert und weitergereicht werden können.
Deshalb muß der µ-Kern eindeutige Identifikatoren, sogenannte “unique identifier”
(uid), für Threads oder Adreßräume oder Kommunikationskanäle bereitstellen. Diese
uids dürfen aus Sicherheitsgründen nach dem Löschen des entsprechenden Objekts
während des Systemlebens nie2 wieder vergeben werden, müssen also zeiteindeutig
sein.
Hat beispielsweise S1 mit Hilfe von Nameserver, Authentisierungs-Server o.ä. oberhalb
des µ-Kerns implementierten Diensten das Subsystem S 2 als Partner identifiziert, kann
es mit Hilfe der entsprechenden uid S 2 als Kommunikationsziel spezifizieren. Entsprechend kann S2 eindeutig S1 als Urheber der Kommunikation identifizieren. Wiederholte
Authentisierung wird damit in beiden Fällen überflüssig.
5.2
Mandatorische Sicherheit (to def)
Autonomie- und Integritätsprinzip stellen sicher, daß sich jedes Subsystem vor Dritten
schützen kann und man Server anbieten kann, die ihre Objekte einer Sicherheitspolitik
unterwerfen. Für die Durchsetzung mandatorischer Sicherheitspolitiken braucht man
zusätzlich:
• Das Supervisionsprinzip: Ein Subsystem S muß so eingerichtet werden können,
daß seine Kommunikation mit allen anderen Subsystemen vollständig von einem
anderen Subsystem S̄ überwacht und modifiziert werden kann.
Hiermit werden Autonomie- und Integritätsprinzip teilweise relativiert und in die Verantwortung von S̄ gelegt. Eine Synthese aller drei Prinzipien erfordert, daß die verschiedenen Subsysteme zweifelsfrei feststellen können müssen, ob und welche Supervisoren
bei ihrer Kommunikation beteiligt sind. Insbesondere braucht man Domänen, in denen
Autonomie und Integrität unbeschränkt gelten. Beispielsweise muß der Kern das für
die Kommunikation zwischen Custodian und Überwachtem sicherstellen.
5.2.1
Clans & Chiefs
Das Clan-Konzept ist eine Realisierung des Supervisionsprinzips. Abbildung 2 zeigt
eine Hierarchie
2
Theoretisch reicht auch eine begrenzte Zeiteindeutigkeit, z.B. für einen Tag. Dann muß aber bei
jeder Kommunikation die Realzeituhr gelesen werden. Bei einem schnellen µ-Kern ist dieser Zusatzaufwand nicht vernachlässigbar.
'
-
y
'
intendierte Kommunikation
umgeleitete
y
- y
$
'
MB
y i
PP
?
i
Pq
i
P i
& %
&
&
9
$
$
%
%
Abbildung 2: Clans & Chiefs.
von Clans (Ovale), die jeweils aus ein oder mehreren Tasks (Kreise) und/oder inneren
Clans bestehen. Die Außenkommunikation jedes Clans wird von seinem Chief kontrolliert. Diese Chiefs sind normale Tasks, die in der Abbildung als schwarz gefüllte Kreise
dargestellt werden.
Innerhalb eines Clans gilt das Integritätsprinzip ohne Einschränkung. Die Kommunikation wird direkt vom µ-Kern durchgeführt. Aber immer wenn bei einer Kommunikation mindestens eine Clangrenze überschritten wird, leitet der µ-Kern die Botschaft
zum nächstgelegenen Chief um. Dieser kann sie inspizieren, modifizieren, weiterleiten,
umleiten oder unterdrücken.
Neben anderen Anwendungen, wie Tracing, Emulation, rechnerübergreifender Kommunikation (Remote IPC), lassen sich auch Custodians hiermit realisieren. Bei geeigneter
Realisierung [22] können beide Partner immer statisch feststellen, ob bei einer Kommunikation überhaupt ein Chief involviert sein wird, ob nur vertrauenswürdige Chiefs
involviert werden oder ob der Kommunikationspfad über verdächtige Chiefs läuft.
5.2.2
Ports als Alternative
Statt des Clan-Konzepts kann der µ-Kern auch ein Port-Konzept realisieren. Der prominenteste Vertreter dieser Richtung ist Mach [1]. Tasks können dabei nur über Ports
kommunizieren, für die sie von anderen Tasks Portrechte bekommen haben. Bei der
Erzeugung erhält jede Task einen initialen Satz an Portrechten, über die sie dann per
IPC Zugriff zu weiteren Ports erhalten kann.
Um eine Clan-ähnlichen Effekt zu erzielen, darf man jeder neuen Task anfänglich nur
Portrechte zur Kommunikation mit mit solchen vertrauenswürdigen Tasks gestatten,
die der neuen Task ihrerseits nur Ports zu ebenso vertrauenswürdigen Partnern geben. Direkte Kommunikation mit potentiell nicht vertrauenswürdigen Tasks wird somit
unmöglich gemacht.
Das hier skizzierte Verfahren hat zwei wesentliche Nachteile. Einmal ist es sehr fehleranfällig und in der Praxis oft nicht durchsetzbar. Zum anderen ist nicht klar, ob sich
Port-basierte Kommunikation genauso effizient realisieren läßt wie direkte Kommunikation zwischen Threads, kontrolliert durch das Clan-Konzept. 3
3
Leider ist Mach als ganzes und Mach-IPC im speziellen sehr ineffizient [8, 24]. Wir wissen, daß
man IPC (auf 486-Rechnern) etwa 20 mal schneller [23] realisieren kann als Mach. Wegen dieser teu-
6
10
Realisierung von Custodians
Hier müssen wir zwischen (a) Sicherheitspolitiken, die vollständig durch sichere Server
realisiert werden können, unterscheiden und solchen, die die Überwachung einiger oder
aller Klienten (besserer Begriff statt ‘Klient’ !?) erforden. Beispiele
6.1
Kommunikation
Wenn im Fall (a) die Server mit der Sicherheitspolitik kooperieren, können Custodians
durch geeignete Programmierung in den Adreßraum jedes Servers integriert werden.
Oft sind die Server aber nicht für den Anschluß von Custodians vorbereitet oder sind
sogar selbst potentiell verdächtig. In diesem Fall unkooperativer Server (siehe Abb. 3),
kann man die Server si einzeln oder gruppenweise durch Clans kapseln. Die Custodians
kk
1
HH
kk
2
- {
#
'{
HH
?
sk
2
j
H sk
1
"!
&
sk
3
$
%
Abbildung 3: Unkooperative Server.
werden dann als Chief-Tasks realisiert. Die Klienten k i können dabei frei untereinander
kommunizieren, bei den Servern setzen die Chiefs aber die jeweilige Sicherheitspolitik
durch.
Wenn die Sicherheitspolitik verlangt, potentiell verdächtige Klienten zu überwachen
(Fall (b)), muß man diese durch Clans kapseln (Abb. 4). Falls Inter-Server-Kommunikation
{
#
{
#
- sk
1
2
6 s1k
"!
"!
kk
2
kk
1
sk
3
Abbildung 4: Klientenüberwachung.
für die Sicherheitspolitik unbedeutend ist oder die Server vertrauenswürdig sind, können
Klienten- und Server-Custodians zusammen als Klienten-Chief implementiert werden.
Sind die Server verdächtig oder unkooperativ, müssen sowohl Klienten als auch Server
durch Clans gekapselt werden.
6.2
Mapping
In vielen Sicherheitspolitiken können die meisten Objektzugriffe mittels Mapping anstelle von IPC realisiert werden. Dateien und andere Objekte, deren innere Konsistenz
ren Implememtierung sind die relativen Kosten der Portrechte bei Mach unbedeutend, nicht aber bei
einem wirklich effizienten µ-Kern. Gesicherte Erkenntnisse dazu gibt es mangels einer effizienten Machkompatiblen Implementierung nicht. Aus unserer Erfahrung erwarten wir jedoch eine Verlangsamung
um einen Faktor zwischen 1.2 und 2, vor allem, weil die Cache-Workingsets aufgrund der Verwaltung der Portrechte wachsen. Demgegenüber sind die Kosten des Clan-Konzepts bei Kommunikation
innerhalb eines Clans vernachlässigbar: weniger als 1% der minimalen IPC-Kosten.
11
aus Sicht der Sicherheitspolitik irrelevant ist, können von den Servern ganz oder teilweise in den Adreßraum der jeweiligen Klienten gemappt werde (Abb. 5). Map- und
Klienten Adreßraum
A
' A
A
&
A
A
A
A
A
{
Server Adreßraum
$
%
Abbildung 5: Kontrolliertes Mapping.
grant-Operation sind als spezielle Kommunikationsart realisiert sind und unterliegen
damit der IPC-Kontrolle des Chiefs. Somit kann der Clan, der im Beispiel den Server
kapselt, auch hier das Mapping kontrollieren.
In diesem Modell wird der Custodian im wesentlichen nur zum Öffnen einer Datei bemüht. Danach können Schreib-/Lesezugriffe direkt im Adreßraum des Klienten
durchgeführt werden, d.h. read- und write-Operationen werden durch die Sicherheitspolitik nicht verteuert. Änderungen der Sicherheitspolitik sind jederzeit möglich, da
der Chief Mappings jederzeit aufheben oder einschränken kann.
7
Conclusio
Viele sensitive Anwendungen erfordern anwendungsspezifische und teilweise einander
widersprechende Sicherheitspolitiken. Das breite Spektrum verhindert eine Integration der Sicherheitspolitik(en) in den Betriebssystemkern. Stattdessen muß der Kern
einige wenige Basismechanismen zur Verfügung stellen, mit deren Hilfe möglichst viele Politiken realisiert werden können. Zusätzlich zum Adreßraum- und RPC-Konzept
benötigen Sicherheitspolitiken Custodians oder etwas Vergleichbares.
Diese Sicherheits-Basiskonzepte lassen sich einfach und effizient auf die vorgestellten
µ-Kern-Mechanismen abbilden. µ-Kerne stellen höheren Ebenen beispielsweise Prozeßkommunikation und Clans zur Verfügung. Custodians, d.h. anwendungsspezifische
Kommunikationsüberwachung, kann durch Clans realisiert werden. Adreßräume, ein
weiteres µ-Kern-Konzept, können mit Hilfe der Basismechanismen map, flush und grant
anwendungsspezifisch außerhalb des µ-Kerns realisiert und kontrolliert werden.
Referenzen
[1] M. J. Accetta, R. V Baron, W. Bolosky, D. B. Golub, R. F. Rashid, A. Tevanian,
and M. W. Young. Mach: A new kernel foundation for unix development. In
Usenix Summer Conference, pages 93–113, Atlanta, GA, June 1986.
[2] N. Batlivala, B. Gleeson, J. Hamrick, S Lurndal, D. Price, J. Soddy, and V. Abrossimov. Experience with SVR4 over Chorus. In Usenix Workshop on Micro-Kernels
and Other Kernel Architectures, pages 223–241, Seattle, WA, April 1992.
12
[3] D.E. Bell and L.J. LaPadula. Secure Computer System: Unified Exposition and
Multics Interpretation. Technical Report AD-A023 588, MITRE, March 1976.
[4] B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, safety and performance in the Spin operating system. In 15th ACM Symposium on Operating System Principles (SOSP),
pages xx–xx, Copper Mountain Resort, CO, December 1995.
[5] David F.C. Bewer and Michael J. Nash. The Chinese Wall Security Policy. In
Proceedings of the Symposium on Security and Privacy, pages 206–214. IEEE
Computer Society Press, May 1989.
[6] K.J. Biba. Integrity Considerations for Secure Computer Systems. Technical
Report ESD-TR-76-372, MITRE, Bedford, Massachusetts, April 1977.
[7] C. Bryce and G. Muller. Matching micro-kernels to modern applications using finegrained memory protection. In IEEE Symposium on Parallel Distributed Systems,
San Antonio, TX, October 1995.
[8] J. B. Chen and B. N. Bershad. The impact of operating system structure on
memory system performance. In 14th ACM Symposium on Operating System
Principles (SOSP), pages 120–133, Asheville, NC, December 1993.
[9] D. R. Cheriton and K. J. Duda. A caching model of operating system kernel
functionality. In 1st USENIX Symposium on Operating Systems Design and Implementation (OSDI), pages 179–194, Monterey, CA, November 1994.
[10] D. R. Cheriton, G. R. Whitehead, and E. W. Sznyter. Binary emulation of Unix
using the V kernel. In Usenix Summer Conference, pages 73–86, Anaheim, CA,
June 1990.
[11] David D. Clark and David R. Wilson. A Comparsion of Commercial and Military
Computer Security Policies. In Proceedings of the Symposium on Security and
Privacy, pages 184–194. IEEE Computer Society, April 1987.
[12] Department of Defense. Trusted Computer System Evaluation Criteria, August
1983.
[13] R. P. Draves, B. N. Bershad, R. F. Rashid, and R. W. Dean. Using continuations
to implement thread management and communication in operating systems. In
13th ACM Symposium on Operating System Principles (SOSP), pages 122–136,
Pacific Grove, CA, October 1991.
[14] D. Engler, M. F. Kaashoek, and J O’Toole. Exokernel, an operating system
architecture for application-level resource management. In 15th ACM Symposium
on Operating System Principles (SOSP), pages xx–xx, Copper Mountain Resort,
CO, December 1995.
[15] B. Ford and J. Lepreau. Evolving Mach 3.0 to a migrating thread model. In
Usenix Winter Conference, pages 97–114, CA, January 1994.
13
[16] M. Gasser, A. Goldstein, C. Kaufmann, and B. Lampson. The Digital distributed
system security architecture. In 12th National Computer Security Conference
(NIST/NCSC), pages 305–319, Baltimore, 1989.
[17] D. Golub, R. Dean, A. Forin, and R. Rashid. Unix as an application program. In
Usenix Summer Conference, pages 87–96, Anaheim, CA, June 1990.
[18] M. Guillemont, J. Lipkis, D.Orr, and M. Rozier. A second generation micro kernel
based Unix. In Usenix Winter Conference, pages 13–22, Dallas, TX, January 1991.
[19] Hermann Härtig, Winfried E. Kühnhauser, and Oliver C. Kowalski. The BirliX
Security Architecture. Journal of Computer Security, IOS Press, 2(1):5–21, 1993.
[20] Winfried E. Kühnhauser. A Paradigm for User-Defined Security Policies. In
Proceedings of the 14th IEEE Symposium on Reliable Distributed Systems, Bad
Neuenahr, Germany, September 1995. IEEE Computer Society Press.
[21] Winfried E. Kühnhauser and Michael von Kopp Ostrowski. A Formal Framework
to Support Multiple Security Policies. In Proceedings of the 7th Canadian Computer Security Symposium, Ottawa, Canada, May 1995. Communication Security
Establishment Press.
[22] J. Liedtke. Clans & chiefs. In 12. GI/ITG-Fachtagung Architektur von Rechensystemen, pages 294–305, Kiel, March 1992. Springer.
[23] J. Liedtke. Improving IPC by kernel design. In 14th ACM Symposium on Operating System Principles (SOSP), pages 175–188, Asheville, NC, December 1993.
[24] J. Liedtke. On µ-kernel construction. In 15th ACM Symposium on Operating
System Principles (SOSP), pages xx–xx, Copper Mountain Resort, CO, December
1995.
[25] Wolfgang Lux. Integrating Custodians into OSF-DCE. In Proceedings of the
Workshop on Anwendungsunterstützung für heterogene Revchnernetze, Freiberg,
Germany, March 1995. Technical University of Freiberg Press.
[26] Ravi S. Sandhu. A Lattice Interpretation of the Chinese Wall Policy. In Proceedings of the 15th National Computer Security Conference, pages 329–339. NISTNCSC, United States Government Printing Office: 1992-625-512:60546, 1992.
[27] Jennifer G. Steiner, Clifford Neuman, and Jeffrey I. Schiller. Kerberos: An Authentication Service for Open Network Systems. In Usenix Winter Conference,
January 1988.
[28] A. S. Tanenbaum, S. J. Mullender, and R. van Renesse. Using sparse capabilities
in a distributed operating system. In 6th International Conference on Distributed
Computing Systems, pages 558–563, Cambridge, MA, May 1986.
[29] R. van Renesse, H. van Staveren, and A. S. Tanenbaum. Performance of the
world’s fastest distributed operating system. Operating Systems Review, 22(4):25–
34, October 1988.

Sicherheit in Betriebssystemen

Transcrição

Documentos relacionados

7.¨Ubung ” Nebenläufige und verteilte Programmierung“

LingoPAD Wö rterbuch Anleitung

Ausgabe 08 September 2010 - open-end-music

Aktueller Kursflyer - Food

Gottes Wirken in meinem Leben

Frauenleiden intim (März 2013)

Full Text

Neuer Pastor in der Philadelphia Kirche

PDF / 33 kB - Forschungszentrum Jülich

¨Ubungen zu Computergraphik I