Die Quellen des RSBAC-Paketes sind in zwei Teile unterteilt, die Kernerweiterungen in den Dateien rsbac-patch-*.gz und die Administrationswerkzeuge in den Dateien rsbac-admin-*.tar.gz, die getrennt zu installieren sind. Alle Quellen sind über das Internet unter http://www.rsbac.org zu beziehen. Grundkenntnisse im Umgang mit Unix-Systemen werden hier vorausgesetzt.
Zwingende Grundlage der Installation sind die Linux-Kernquellen in der angegebenen Version. Diese sind üblicherweise in einer Datei namens linux-2.0.xx.tar.gz erhältlich, die z.B. im Verzeichnis /usr/src mit dem Befehl tar xvzf linux-2.0.xx.tar.gz zu entpacken ist. Dabei wird ein Unterverzeichnis linux erzeugt, das in linux-2.0.xx-rsbac umbenannt werden sollte, um Verwechslungen zu vermeiden. Existieren bereits ein Verzeichnis oder eine Datei mit dem Namen linux, sind diese natürlich vorher zu löschen oder umzubenennen. Für den gesamten Quellbaum inklusive RSBAC sind mindestens 30 MB zu veranschlagen.
Anschließend ist die Datei rsbac-patch-*.gz mit gzip -d rsbac-patch-*.gz zu dekomprimieren. Ich empfehle, die entstandene Datei rsbac-patch-* ebenfalls in das Verzeichnis /usr/src zu kopieren. Ist das geschehen, können im Kernquell-Hauptverzeichnis /usr/src/linux-2.0.xx-rsbac mit dem Befehl patch -p1 </usr/src/rsbac-patch-* die Kernerweiterungen eingespielt werden. Da das Protokoll auf die Standard-Fehlerausgabe geschrieben wird, kann durch Anhängen von 2>/usr/src/err an den Befehl eine Protokolldatei erzeugt und anschließend überprüft werden. Schlägt die Erweiterung fehl, sollte der gesamte Quellbaum neu erzeugt werden, da eine Wiederholung der Anpassung problematisch ist.
Bei der Erweiterung eines bereits vorhandenen und anderweitig veränderten Quellbaumes kann es passieren, daß Fehler entstehen oder Teile zurückgewiesen werden. Dann ist es sinnvoll, eine Protokolldatei erzeugen zu lassen und gründlich zu prüfen, ob alle Änderungen wie vorgesehen durchgeführt wurden. Selbstverständlich sollte vor jeder Änderung eine Sicherheitskopie des Urzustandes angelegt werden.
Die Konfiguration des Kernes erfolgt durch die üblichen Konfigurationsprogramme, z.B. durch Eingabe von make menuconfig im Quellhauptverzeichnis. Das Konfigurationsmenü enthält jetzt ein weiteres Untermenü Rule Set Based Access Control, in dem die Einstellungen der folgenden Liste aktiviert werden können:
Nach der Konfiguration kann der Kern wie gewohnt übersetzt und installiert werden. Vor dem Neustart mit diesem Kern ist unbedingt eine der useraci-Dateien aus dem Administrationspaket in das Verzeichnis /rsbac zu kopieren (make install im zugehörigen Verzeichnis), da der Systemstart ohne den eingetragenen Administrator root nicht möglich ist! Außerdem sollten ein Sicherheitsbeauftragter mit der Benutzernummer 400 und, falls das Datenschutzmodell verwendet werden soll, ein Datenschutzbeauftragter mit der Nummer 401 eingerichtet werden. Die verwendeten Kennungen können dann später geändert werden.
Erscheint beim Systemstart eine Meldung rsbac_init(): User ACI could not be read und fährt das System nicht vollständig hoch, so ist die kopierte Datei für das verwendete System unbrauchbar. In diesem Fall sind mit einem Warmstart ein unveränderter Kern hochzufahren, in der Kernkonfiguration alle Politiken zu deaktivieren (RSBAC an, aber alle Module abgeschaltet) sowie damit ein neuer Wartungskern zu erzeugen und ebenfalls in das LILO-Startmenü einzutragen. Mit dem Wartungskern können die Administrationswerkzeuge verwendet werden, um die benötigten Rollen neu zu setzen.
Beim Start des Systems ermöglicht der Linux-Loader (LILO), dem Kern Parameter zu übergeben, die sein Verhalten beeinflussen. Die von den RSBAC-Erweiterungen akzeptierten Parameter zeigt die folgende Liste:
Die Administrationswerkzeuge in der Datei rsbac-admin-*.tar.gz können in einem beliebigen Verzeichnis, z.B. /root/rsbac, mit dem Befehl tar xvzf rsbac-admin-*.tar.gz ausgepackt werden. Danach sind in Makefile die Pfade zum Verzeichnis der Kernquellen, für die Programminstallation und für die Hilfe-Seiten (man-Seiten) anzupassen.
Mit make werden die Hilfsprogramme erzeugt, mit make install installiert und mit make allclean das Verzeichnis wieder aufgeräumt. Falls sie nicht existiert, erzeugt make install außerdem die Datei /rsbac/useraci, die die benötigten Benutzerattribute für den Systemstart und die Administration enthält.
Die allgemeine Administration erfolgt ausschließlich über Kommandozeilen. Dazu existieren mehrere Hilfsprogramme, die sich der neuen Systemaufrufe bedienen. Jedes dieser Programme gibt beim Aufruf ohne Parameter eine kurze Hilfe aus. Die Überprüfung der Berechtigung des jeweiligen Aufrufes erfolgt in den Systemaufrufen. Die folgende Liste bietet eine kurze Beschreibung der Befehle:
Bis auf das Datenschutzmodell erfolgt die gesamte Administration aller implementierten Sicherheitsmodelle durch das Setzen entsprechender Attribute. Dieses ist aber nur Benutzern mit der System-Rolle Sicherheitsbeauftragter gestattet, die bei der Installation für Benutzer Nr. 400 eingetragen wird. Ist kein Sicherheitsbeauftragter vorhanden, muß, wie oben beschrieben, ein Wartungskern ohne Sicherheitsmodule erzeugt und mit diesem die Neuverteilung der Rollen vorgenommen werden.
Die zu setzenden Attribute sind bei den Modellen beschrieben. Zudem werden dort die den verwendeten Systemaufrufen zugrundeliegenden Datentypen vorgestellt, in denen sich alle verwendbaren Attribute wiederfinden. Die exakte Schreibweise ist der jeweiligen Kurzhilfe der Befehle zu entnehmen. Eine eventuell benötigte Ordnungsnummer ergibt sich aus dem Datentyp des Attributs und ist ebenfalls der Kurzhilfe zu entnehmen.
Sobald das Datenschutzmodul aktiv ist, können keine für dieses Modul relevanten Attribute mit den bisher genannten Befehlen mehr gesetzt werden. Stattdessen erfolgt die gesamte Verwaltung mit dem Programm rsbac_pm, das hauptsächlich eine Eingabeschnittstelle zu dem gleichlautenden, Ticket-basierten Systemaufruf ist. Allerdings können hier an Stelle von Ordnungsnummern auch die jeweiligen Bezeichnungen verwendet werden, beispielsweise security_officer bei der Funktion set_role.
Da die Vergabe von PM-Rollen nur mit Tickets möglich ist, muß jeweils mindestens ein Benutzer mit der Rolle Sicherheitsbeauftragter und der Rolle Datenschutzbeauftragter existieren, was bei den Installation sichergestellt sein sollte. Ansonsten sind der schon beschriebene Wartungskern zu installieren und die Rollen mit attr_set_up USER pm_role Ordnungsnummer Benutzernummer zu setzen.
Bei den Administrationswerkzeugen befinden sich noch weitere Programme, deren Verwendung hier kurz erläutert werden soll. Selbstverständlich unterliegen diese Programme der Zugriffskontrolle.
Zur Demonstration des Systems ist in Zusammenarbeit mit Simone Fischer-Hübner ein vereinfachtes Anwendungsbeispiel entstanden, das zwar mehrere der implementierten Sicherheitsmodelle verwendet, sich aber auf das umfangreichste, das Datenschutzmodell, konzentriert. Weitere Module können natürlich jederzeit dazugeschaltet werden.
Für eine kleinere Operationsklinik ist elektronische Datenverarbeitung zu betreiben. Dabei soll der Datenschutz für sämtliche Patientendaten gewährleistet, aber auch Forschung in Form von statistischer Auswertung des Operationsverlaufes betrieben werden. Die Grundsätze minimalen Wissens und größtmöglicher Aufgabentrennung sind außerdem zu beachten.
Die Vorhaltung und Verarbeitung der Daten soll innerhalb eines geschützten Systems ohne Fremdzugriffe und Weitergabe betrieben werden. Die einzigen Ausnahmen sind die Weitergabe der Abrechnungdaten eines Patienten an die zuständige Krankenkasse und die Übermittlung der Diagnose bei einer Überweisung zu einer anderen Behandlungsstelle. Beides erfolgt über eine bestehende, angemessen gesicherte Netzwerkverbindung.
Der Gesamtaufenthalt eines Patienten soll folgende Schritte durchlaufen:
Zunächst sind die Zwecke der Datenspeicherung mit ihren zugeordneten Aufgaben festzulegen:
Zweck | Behandlung | Verwaltung | Forschung |
---|---|---|---|
Aufgaben | Diagnose | Aufnahme | Statistik |
Operation | Entlassung | ||
Therapie | Abrechnung | ||
Überweisung | Datenweitergabe |
Zur Speicherung der Daten sind Objektklassen mit zugeordneten Zwecken zu definieren:
Objektklasse | Zwecke | Inhalte |
---|---|---|
Aufnahmedaten | Verwaltung | Grunddaten des Patienten |
Abrechnungsdaten | Verwaltung | Abrechnung der erbrachten Leistungen |
Befund | Behandlung | Diagnosedaten |
Behandlungsauftrag | Behandlung | Anweisungen an Operateure und Therapeuten |
OP-Daten | Behandlung | Verlauf der Operation |
Leistungsdaten | Verwaltung, Behandlung | Erbrachte Leistungen |
Statistiken | Forschung | Auswertungen der Operationsverläufe |
Als nächstes werden Benutzer definiert und für ihre Aufgaben autorisiert:
Benutzer | Autorisierte Aufgaben |
---|---|
Internist | Diagnose, Therapie, Überweisung |
Chirurg | Operation, Überweisung |
Therapeut | Therapie |
Verwalter | Aufnahme, Entlassung |
Buchhalter | Abrechnung, Datenweitergabe |
Forscher | Statistik |
Zur Verarbeitung der Daten werden folgende Transformationsprozeduren definiert:
TP | Einsatz |
---|---|
pm_create | Erzeugen von Dateien einer Klasse |
Anfüge-Editor | Erfassen eines Textes und Anhängen an eine Datei |
Editor | Ändern einer Textdatei |
Anzeigeprogramm | Bildschirmanzeige einer Textdatei |
Löschprogramm | Löschen einer Datei |
Weitergabeprogramm | Verschlüsselte Weitergabe von Dateiinhalten über Interprozeßkommunikation |
Statistikprogramm | Lesen einer Datei, Erstellen einer Statistik und Schreiben in eine andere Datei |
Der nächste Schritt ist die Bestimmung der autorisierten Transformationsprozeduren aller Aufgaben:
Aufgabe | Autorisierte TP |
---|---|
Diagnose | pm_create, Anfüge-Editor, Editor, Anzeigeprogramm |
Operation | pm_create, Anfüge-Editor, Editor, Anzeigeprogramm |
Therapie | Anfüge-Editor, Anzeigeprogramm |
Überweisung | Weitergabeprogramm |
Aufnahme | pm_create, Editor |
Entlassung | Anfüge-Editor |
Abrechnung | Editor, Anzeigeprogramm |
Datenweitergabe | Weitergabeprogramm |
Statistik | pm_create, Editor, Statistikprogramm |
Schließlich ist als letztes die Menge der notwendigen Zugriffe zu bestimmen. Die möglichen Zugriffsarten sind Lesen, Schreiben, Löschen, Erzeugen und Anfügen.
Aufgabe | Objektklasse | TP | Zugriffe |
---|---|---|---|
Diagnose | Befund | pm_create | Erzeugen |
" | " | Editor | Lesen, Schreiben, Anfügen |
" | " | Anzeigeprogramm | Lesen |
" | Leistungsdaten | Anfüge-Editor | Anfügen |
" | Behandlungsauftrag | pm_create | Erzeugen |
" | " | Editor | Lesen, Schreiben, Anfügen |
Operation | Behandlungsauftrag | Anzeigeprogramm | Lesen |
" | OP-Daten | pm_create | Erzeugen |
" | " | Editor | Lesen, Schreiben, Anfügen |
" | Leistungsdaten | Anfüge-Editor | Anfügen |
Therapie | Behandlungsauftrag | Anzeigeprogramm | Lesen |
" | Leistungsdaten | Anfüge-Editor | Anfügen |
Überweisung | Befund | Weitergabeprogramm | Lesen |
" | Behandlungsauftrag | Weitergabeprogramm | Lesen |
" | Interprozeßkommunikation | Weitergabeprogramm | Erzeugen, Schreiben, Anfügen |
Aufnahme | Aufnahmedaten | pm_create | Erzeugen |
" | " | Editor | Lesen, Schreiben, Anfügen |
" | Leistungsdaten | pm_create | Erzeugen |
" | " | Anfüge-Editor | Anfügen |
Entlassung | Aufnahmedaten | Anfüge-Editor | Anfügen |
" | Leistungsdaten | Anfüge-Editor | Anfügen |
Abrechnung | Leistungsdaten | Anzeigeprogramm | Lesen |
" | Abrechnungsdaten | pm_create | Erzeugen |
" | " | Editor | Lesen, Schreiben, Anfügen |
Datenweitergabe | Abrechnungsdaten | Weitergabeprogramm | Lesen |
" | Interprozeßkommunikation | Weitergabeprogramm | Erzeugen, Schreiben, Anfügen |
Statistik | Statistikdaten | pm_create | Erzeugen |
" | " | Editor | Lesen, Schreiben, Anfügen |
" | " | Löschprogramm | Löschen |
" | " | Statistikprogramm | Schreiben, Anfügen |
" | Befund | Statistikprogramm | Lesen |
" | Behandlungsauftrag | Statistikprogramm | Lesen |
" | OP-Daten | Statistikprogramm | Lesen |
Für das PM-Modul sind in der aktuellen Fassung alle genannten Bezeichnungen als Zahlenwert zu kodieren und über Tickets mit rsbac_pm einzugeben.
Da das PM-Modell nur personenbezogene Daten und Administrations-Systemaufrufe vor Unbefugten schützt, bleiben andere Dateien und Verzeichnisse von der diskreten Rechteverwaltung abhängig. Es liegt nahe, diese durch mindestens ein anderes Modell vor Zugriffen zu schützen. Aufgrund der höheren Sicherheit sollte aber zumindest die Authentisierungsdatei /etc/shadow als personenbezogen mit eigener Objektklasse definiert und das Öffnen über notwendige Zugriffe beschränkt werden.
Für dieses Beispiel bietet sich die Verwendung der funktionalen Kontrolle an, um den Zugriff auf alle anderen sicherheitsrelevanten Dateien und Verzeichnisse über die Objektkategorien Sicherheits- und Systemobjekt einzuschränken. Für die sicherheitsrelevanten Objekte, die, wie die Identifizierungsdatei /etc/passwd, nur nicht unbefugt verändert werden sollen, kann das Sicherheits-Informations-Modifikations-Modell (SIM) mit dem Attribut Datentyp eingesetzt werden.
Das mandatorische Modell ist dann zusätzlich sinnvoll, wenn auch vertrauliche, nicht-personenbezogene Daten abzulegen sind, z.B. Geschäftsdaten.
Der Durchgang eines Patienten durch die Klinik wird durch folgende Schritte abgebildet:
Bei Bedarf kann der Patient außerdem an einen anderen Arzt oder eine andere Klinik überwiesen werden. Dazu können bisherige Diagnose und Behandlungsauftrag verschlüsselt per Netzwerk übermittelt werden.
Wie der Internist kann der Chirurg den Patienten bei Bedarf an einen anderen Arzt oder eine andere Klinik überweisen und Diagnose- und Behandlungsauftragsdaten dorthin übertragen.
Zurück zur RSBAC-Hauptseite
-05-Mar-99, -ao