DE3851049T2

DE3851049T2 - Ein Sicherheitswegmechanismus für ein Betriebssystem.

Info

Publication number: DE3851049T2
Application number: DE3851049T
Authority: DE
Inventors: Abhai Johri; Gary Linn Luckenbaugh
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1988-01-28
Filing date: 1988-12-22
Publication date: 1995-03-09
Anticipated expiration: 2008-12-23
Also published as: EP0325776A2; DE3851049D1; EP0325776A3; US4918653A; EP0325776B1; JPH01233543A

Description

1. Technisches Gebiet

Die offenbarte Erfindung betrifft allgemein die Datenverarbeitung und insbesondere die Herstellung eines Sicherheitswegs zwischen Teilen eines Datenverarbeitungssystems.

2. Stand der Technik

Viele Datenverarbeitungsanwendungen wie beispielsweise Anwendungen im Finanzbereich, im Bereich der nationalen Sicherheit und dergleichen betreffen streng vertrauliche Informationen, bei denen die Informationen durch einen Benutzer in das Datenverarbeitungssystem eingegeben werden, der diese Informationen an einer an das System angeschlossenen Benutzerdatenstation eintippt. Bisher steht nach dem Stand der Technik kein wirksamer Mechanismus zur Verfügung, mit dem verhindert werden kann, daß nicht berechtigte Personen oder Programme Daten aus der Benutzerdatenstation lesen. Bei den Datenverarbeitungssystemen nach dem Stand der Technik kann ein als Trojanisches Pferd bekanntes unberechtigtes Programm, das sich als das Programm tarnen kann, mit dem Benutzer kommunizieren möchte, und das die Sicherheit der durch den Benutzer an seiner Datenstation eingegebenen vertraulichen Informationen umleiten, kopieren oder anderweitig untergraben kann, den Kommunikationspfad zwischen der Datenstation des Benutzers und der Software des Betriebssystems entweder nachmachen oder in ihn eindringen.
Für Anwendungen im Bereich der nationalen Sicherheit hat die amerikanische Regierung einen Standard festgelegt, nach dem die Sicherheit von Datenverarbeitungssystemen beurteilt werden kann; dieser Standard wurde in "Trusted Computer System Evaluation Criteria", U. S. Department of Defense, Dezember 1985, DoD publication number 5200.28-STD (hier als DoD Standard bezeichnet) veröffentlicht. Im DoD Standard wird ein gesichertes Computersystem als ein System definiert, dessen Hardware- und Software-Schutzmaßnahmen dazu ausreichen, daß es zur Verarbeitung einer Vielzahl von vertraulichen oder geheimen Informationen verwendet werden kann. Als Computersicherheitsbasis (TCB = Trusted Computing Base) wird die Gesamtheit der Schutzmechanismen innerhalb eines Computersystems - einschließlich Hardware, Firmware und Software - definiert, durch deren Kombination eine Sicherheitspolitik erzwungen wird. Eine TCB besteht aus einer oder mehreren Komponenten, die zusammen eine einheitliche Sicherheitspolitik für das Produkt oder System erzwingen. Die Fähigkeit einer TCB, eine Sicherheitspolitik in korrekter Weise zu erzwingen, hängt ausschließlich von den Mechanismen innerhalb der TCB und von der richtigen Eingabe sicherheitsbezogener Parameter wie der Benutzerberechtigungen durch die Systemverwalter ab. Ein gesicherter Pfad wird im DoD Standard als ein Mechanismus definiert, mit dessen Hilfe ein Benutzer einer Datenstation direkt mit der Computersicherheitsbasis kommunizieren kann. Der gesicherte Pfad kann nur von dem betreffenden Benutzer oder von der Computersicherheitsbasis aktiviert und nicht von Software, die nicht gesichert ist, nachgeahmt werden. Gesicherte Software ist als der Software-Bestandteil einer Computersicherheitsbasis definiert.
Das Problem, einen Sicherheitsweg zwischen einer Benutzerdatenstation und einer Computersicherheitsbasis aufrechtzuerhalten, wird bei jenen Betriebssystemen erschwert, die mehrere Benutzer bedienen. Einige Beispiele für Mehrplatzbetriebssysteme, die beim heutigen Stand der Technik keinen wirksamen Mechanismus für die Einrichtung eines Sicherheitswegs zur Verfügung stellen, sind UNIX (UNIX ist ein Warenzeichen der AT&T Laboratories), XENIX (XENIX ist ein Warenzeichen der Microsoft Corporation) und AIX (AIX ist ein Warenzeichen der IBM Corporation). UNIX wurde entwickelt und ist lizenziert von AT&T für einen weiten Bereich von Minicomputern und Mikrocomputern. Für weitere Informationen zu UNIX wird der Leser auf "UNIX (TM) System, Users Manual, System V", herausgegeben von der Western Electric Company, Januar 1983, verwiesen. Einen guten Überblick über das Betriebssystem UNIX bieten Brian W. Kernighan und Rob Pike in ihrem Buch "The UNIX Programming Environment", herausgegeben von Prentice- Hall (1984). Eine eingehendere Beschreibung des Aufbaus des Betriebssystems UNIX findet sich in einem Buch von Maurice J. Bach, "Design of the UNIX Operating System", herausgegeben von Prentice-Hall (1986).
AT&T Bell Laboratories haben einer Reihe von Gesellschaften Lizenzen zum Gebrauch des Betriebssystems UNIX erteilt, und es sind mittlerweile mehrere Versionen verfügbar. Die aktuellste Version von AT&T ist die Version 5.2. Eine andere Version, die als Berkley-Version des UNIX-Betriebssystems bekannt ist, wurde von der University of California in Berkley entwickelt. Microsoft Corporation hat eine Version, die unter ihrem Warenzeichen als XENIX bekannt ist.
Zugleich mit der Ankündigung des IBM RT PC (RT und RT PC sind Warenzeichen der IBM Corporation, RT PC = RISC-Technologie Personal Computer, RISC = Reduced Instruction Set Computer) im Jahre 1985 hat IBM ein neues Betriebssystem mit dem Namen AIX herausgebracht, das auf der Ebene der Anwendungsschnittstelle mit dem Betriebssystem UNIX von AT&T, Version 5.2, kompatibel ist und Erweiterungen des Betriebssystems UNIX, Version 5.2, enthält. Für eine nähere Beschreibung des Betriebssystems AIX wird der Leser auf "AIX Operating System Technical Reference", herausgegeben von der IBM Corporation, 2. Auflage (September 1986) verwiesen.
Die hier beschriebene und beanspruchte Erfindung soll insbesondere einen Mechanismus für die Einrichtung eines Sicherheitswegs in einem Mehrplatzbetriebssystem wie z. B. UNIX, XENIX oder AIX zur Verfügung stellen, damit verhindert wird, daß unberechtigte Programme Daten von einer Benutzerdatenstation lesen. Keines der Mehrplatzbetriebssysteme nach dem Stand der Technik bietet einen Mechanismus für die Einrichtung eines Sicherheitswegs, der unberechtigte Programme wirksam daran hindert, Daten von einer Benutzerdatenstation zu lesen.

Aufgaben der Erfindung

Es ist daher eine Aufgabe der Erfindung, einen Mechanismus für die Einrichtung eines Sicherheitswegs in einem Datenverarbeitungssystem zur Verfügung zu stellen.
Es ist noch eine weitere Aufgabe der Erfindung, einen Mechanismus für die Einrichtung eines Sicherheitswegs in einem Mehrplatzbetriebssystem zur Verfügung zu stellen.
Es ist noch eine weitere Aufgabe der Erfindung, einen Sicherheitswegmechanismus für ein UNIX (TM) -artiges Betriebssystem zur Verfügung zu stellen.

Zusammenfassung der Erfindung

Diese und andere Aufgaben, Merkmale und Vorteile der Erfindung werden durch den hier beschriebenen Sicherheitswegmechanismus für ein Betriebssystem erreicht. Die Erfindung des Sicherheitswegmechanismus stellt sicher, daß die von einem Benutzer über die Tastatur einer Datenstation eingegebenen Daten davor geschützt sind, daß unberechtigte Programme wie auch immer in sie eindringen. Sie ermöglicht dem Benutzer die Einrichtung eines Kommunikationspfads zwischen der Datenstation des Benutzers und der Software des Sicherheitsbetriebssystems, der nicht nachgeahmt und in den nicht eingedrungen werden kann. Der Benutzer kann durch einfaches Drücken einer Taste, Sicherheitsanforderungstaste (Secure Attention Key, SAK) genannt, auf der Tastatur der Datenstation einen Sicherheitsweg einrichten. Dieser Vorgang kann aufgerufen werden, wenn sich der Benutzer beim System anmeldet, um sicherzugehen, daß der Benutzer mit dem echten Anmeldeprogramm (Programm login) kommuniziert und nicht mit einem Trojanischen Pferd, das sich als Anmeldeprogramm tarnt und sich dann das Kennwort des Benutzers unberechtigt verschafft. Nachdem der Benutzer einen Sicherheitsweg eingerichtet hat, kann er seine vertraulichen Daten, z. B. ein Kennwort, eingeben und sicher sein, daß sein Kennwort nicht durch das Programm eines Eindringlings gestohlen wird. Wenn sich der Benutzer dann wieder vom System abmeldet, kann er sicher sein, daß ihn der Sicherheitsweg auch wirklich vom System abgemeldet hat, so daß ein Trojanisches Pferd die vom Benutzer begonnene Sitzung nicht fortsetzen kann. Die Erfindung ist in einem Datenverarbeitungssystem implementiert, das einen Speicher enthält, der mit einer Vielzahl von Datenstationen verbunden ist, wobei mindestens eine Datenstation eine Tastatur mit einer Sicherheitsanforderungstaste enthält. Die Erfindung ist ein Verfahren in einem UNIX-artigen Betriebssystem, das auf die Sicherheitsanforderungstaste hin einen Sicherheitsweg zwischen der Datenstation und dem gesicherten Shell-Teil einer Computersicherheitsbasis einrichtet, der ein Kindprozeß eines Init-Prozesses unter dem Betriebssystem ist. Das Verfahren schließt ein, daß ein mit der Tastatur verbundener Tastatur-Gerätetreiber die Sicherheitsanforderungstaste erkennt und an den Generator für das Sicherheitsanforderungstasten- Signal die Information ausgibt, daß die Sicherheitsanforderungstaste gedrückt worden ist. Das Verfahren schließt ferner ein, daß der Generator für das Sicherheitsanforderungstasten-Signal an alle Prozesse, die in einer Prozeßgruppe der Datenstation arbeiten, ein SIGSAK-Signal ausgibt, das alle Prozesse in der Prozeßgruppe der Datenstation beendet. Das Verfahren schließt ferner ein, daß das SIGSAK-Signal an Zugriffsberechtigungstabellen geleitet wird, die zu allen Gerätetreibern gehören, die eine Schnittstelle zur Datenstation bilden, um allen Prozessen im Datenverarbeitungssystem außer dem Init-Prozeß die Zugriffsberechtigung zu verweigern. Das Verfahren schließt ferner ein, daß das SIGSAK-Signal bei allen Prozessen im Datenverarbeitungssystem außer dem Init-Prozeß an eine Dateizugriffstabelle geleitet wird, um alle Adreßinformationen, die die mit der Datenstation verbundenen Gerätetreiber betreffen, zu entfernen. Das Verfahren schließt ferner ein, daß der Init-Prozeß einen Systemaufruf "fork" für einen neuen Kindprozeß ausführt. Das Verfahren schließt weiterhin ein, daß ein Systemaufruf "exec" ausgeführt wird, um den neuen Kindprozeß mit einem gesicherten Shell-Prozeß zu überlagern, wobei letzterer Zugriffsberechtigung auf die mit der Datenstation verbundenen Gerätetreiber und eine in der Dateizugriffstabelle definierte Adreßbeziehung zu den mit der Datenstation verbundenen Gerätetreibern besitzt. Dadurch entsteht ein Sicherheitsweg zwischen der Datenstation und dem gesicherten Shell-Prozeß.
Auf diese Weise ist ein Sicherheitsweg entstanden, um die vertraulichen Daten des Benutzers aufzunehmen und zu verarbeiten; danach wird der Sicherheitsweg geschlossen, und der Benutzer kann ohne die Befürchtung weiterarbeiten, daß ein Trojanisches Pferd die Sicherheit seines Systems umgangen hat.

Kurzbeschreibung der Abbildungen

Diese und weitere Aufgaben, Merkmale und Vorteile der Erfindung werden in Verbindung mit den anliegenden Abbildungen besser verständlich.
Fig. 1 ist ein schematisches Diagramm eines mit einem mehrplatzfähigen, UNIX-artigen Betriebssystem arbeitenden Datenprozessors;
Fig. 2 ist ein schematisches Diagramm des Datenprozessors in Fig. 1, der das Merkmal der Sicherheitsanforderungstaste zum Aufrufen eines Sicherheitswegs gemäß der Erfindung enthält;
Fig. 3 ist ein schematisches Diagramm des Datenprozessors in Fig. 2, das die Einrichtung des Sicherheitswegs zeigt.
Fig. 4 zeigt die vom Kernel zur Verwaltung von Prozessen unterhaltenen - Tabellen;
Fig. 5 zeigt, wie der Kernel damit beginnt, die Prozesse aufzubauen, wenn das System initialisiert wird;
Fig. 6 zeigt das Verhältnis von Elternprozeß und Kindprozeß;
Fig. 7 zeigt, wie sich ein Prozeß in einem von mehreren Zuständen befinden kann;
Fig. 8 ist ein Zustandsdiagramm bei gedrückter Sicherheitsanforderungstaste (SAK);
Fig. 9 zeigt den Init-Prozeß;
Fig. 10 schließt sich an Fig. 9 an und zeigt, wie der Init- Prozeß gerade einen Fork-Prozeß aufruft, um einen Kindprozeß zu erzeugen, und dann führt der Kindprozeß einen Getty-Prozeß aus, der die Anfangsanmeldeaufforderung ausgibt und Eigenschaften der Datenstation ermittelt;
Fig. 11 schließt sich an Fig. 10 an und zeigt, daß, wenn der Benutzer seinen Benutzernamen an getty eingegeben hat, getty den Anmeldeprozeß ausführt;
Fig. 12 schließt sich an Fig. 11 an und zeigt, daß nach einer erfolgreichen Anmeldung der Anmeldeprozeß die für diesen Benutzer spezifizierte Login-Shell, z. B. SH, ausführt;
Fig. 13 schließt sich an Fig. 12 an und zeigt, daß der Leitungsdisziplintreiber ein SIGSAK-Signal an alle Prozesse in der Prozeßgruppe der Kontrolldatenstation schickt, wenn der Benutzer die Sicherheitsanforderungstaste (SAK) drückt. Daraufhin stirbt die Login-Shell, und der Init-Prozeß verzweigt zu einem neuen Kindprozeß, der seinerseits einen gesicherten Shell-Prozeß (trusted shell, TSH) ausführt;
Fig. 14 schließt sich an Fig. 13 an und zeigt, daß, wenn das Programm password innerhalb der gesicherten Shell TSH ausgeführt wird, die gesicherte Shell TSH zu einem Kindprozeß verzweigt, der wiederum password aufruft. Wenn der Prozeß password abgeschlossen ist, läuft die gesicherte Shell TSH noch;
Fig. 15 schließt sich an Fig. 14 an und zeigt, daß die gesicherte Shell TSH eine Exit-Funktion ausführt und dadurch den Sicherheitsweg schließt, der zwischen der Benutzerdatenstation und der Computersicherheitsbasis eingerichtet war;
Fig. 16 zeigt einen alternativen Zustand zu dem in Fig. 12 gezeigten Zustand, wobei unter der Shell SH im Mehrprogramm- oder Mehrprozessorbetrieb eine Vielzahl von Prozessen ausgeführt werden können;
Fig. 17 schließt sich an Fig. 16 an und zeigt einen alternativen Fall zu Fig. 13, wobei, wenn die Sicherheitsanforderungstaste gedrückt ist, wodurch das SIGSAK- Signal ausgelöst wird, die Shell SH mit ihrer Vielzahl von aktiven Prozessen beendet wird und der Init-Prozeß die gesicherte Shell TSH erzeugt und dabei, wie zuvor beschrieben, einen Sicherheitsweg einrichtet.
Fig. 18 ist ein schematisches Diagramm eines Verarbeitungszustands für das System, bei dem die Shell SH zwei Prozesse ausführt, ein Kalkulationsprogramm und ein Datenbankprogramm (DB-Programm), mit dem ein als Trojanisches Pferd arbeitendes Programm verknüpft ist;
Fig. 19 zeigt, wie der Benutzer einen Sicherheitsweg zwischen seiner Datenstation und der Computersicherheitsbasis durch das Drücken seiner Sicherheitsanforderungstaste (SAK) einrichten kann, die die Zerstörung der Shell SH und deren entsprechende Prozesse Kalkulationsprogramm und Datenbankverwaltung und, was am wichtigsten ist, die Zerstörung des als Trojanisches Pferd arbeitenden Programms bewirkt. Fig. 19 zeigt, wie der Init-Prozeß gerade den gesicherten Shell-Prozeß TSH einrichtet.
Fig. 20 zeigt, daß der gesicherte Shell-Prozeß TSH, nachdem er die vom Benutzer gewünschte Aufgabe über seinen Sicherheitsweg ausgeführt hat, von sich aus beendet oder verlassen wird und dadurch den Init-Prozeß veranlaßt, die Shell SH neu zu erzeugen;
Fig. 21 ist ein Flußdiagramm des Init-Prozesses gemäß der Erfindung.

Beschreibung der besten Ausführungsform der Erfindung

Um eine verallgemeinerte Beschreibung der Erfindung des Sicherheitswegmechanismus zu geben, ist Fig. 1 als schematisches Diagramm eines Datenprozessors dargestellt, der mit einem UNIX- artigen Mehrplatzbetriebssystem arbeitet. Die Anordnung in Fig. 1 zeigt den typischen Fall für UNIX-artige Betriebssysteme mit einer Vielzahl von Benutzern, die sich denselben Datenprozessor teilen. Fig. 1 zeigt einen Datenprozessor, der einen Mikroprozessor enthält, der mit einem Schreib/Lese-Speicher verbunden ist. An den Schreib/Lese-Speicher ist auch ein Plattenspeicher angeschlossen, auf dem die Betriebssystemdateien und Benutzerdateien verwaltet werden, die selektiv in den Speicher gelesen werden. Das primäre UNIX-artige Betriebssystem ist der Kernel, der in den Speicher geladen wird und die Initialisierungsprozeduren durchführt, wobei er das System organisiert und benötigte Dateien öffnet, die zur Fortführung der Mehrplatzprozeduren benötigt werden. Ebenfalls mit dem Speicher verbunden ist eine Vielzahl von Datenstationen einschließlich der Datenstation A und der Datenstation B. Bei der Initialisierung des Speichers stellt der Kernel einen ersten Bildschirm-Gerätetreiber DD(A), der mit dem Bildschirm D(A) der Datenstation A verbunden ist, sowie den entsprechenden Zeichenpuffer DB(A), der die an den Bildschirm-Gerätetreiber gesendeten Zeichen zwischenspeichert, zur Verfügung. Analog richtet der Kernel einen Tastatur-Gerätetreiber KD(A) (auch Leitungsdisziplintreiber genannt) ein, der mit der Tastatur K(A) der Datenstation A verbunden ist. Mit dem Tastatur-Gerätetreiber KD(A) ist ein Zeichenpuffer KB(A) verbunden, der die von der Tastatur der Datenstation A empfangenen Zeichen zwischenspeichert. Auf ähnliche Weise richtet der Kernel die Hilfsstrukturen für den Bildschirm D(B) und die Tastatur K(B) der Datenstation B ein, nämlich den Bildschirm-Gerätetreiber DD(B), den Zeichenpuffer DB(B), den Tastatur-Gerätetreiber KD(B) und den Zeichenpuffer KB(B).
Betriebssystemprogramme und Anwendungsprogramme, die in einer UNIX-artigen Umgebung arbeiten, werden Prozesse genannt und bestehen aus drei Grundteilen, einem Programmtext-Teil, einem Datenteil und einem Stack- und Benutzerblock-Teil. Damit ein Prozeß eine Schnittstelle zu E/A-Geräten wie z. B. einer Datenstation hat, muß eine Datei für den aufrufenden Prozeß geöffnet werden, die den Zeichenpuffer benennt, der die Datenstation bedient. Somit muß ein Prozeß wie z. B. der Prozeß A1 in Fig. 1, der mit der Datenstation A verbunden werden muß, mindestens zwei Dateien öffnen: die erste Datei für die Verbindung mit dem Zeichenpuffer DB(A) für den Bildschirm-Gerätetreiber DD(A) und die zweite zu öffnende Datei für die Verbindung mit dem Zeichenpuffer KB(A) für den Tastatur-Gerätetreiber KD(A). Die tatsächliche Kommunikation zwischen einem Prozeß und dem entsprechenden Zeichenpuffer, mit dem er verbunden werden muß, erfolgt über eine Dateizugriffstabelle wie sie Fig. 1 zeigt, die den jeweiligen Prozeß mit dem entsprechenden Zeichenpuffer verknüpft.
Wie Fig. 1 zu entnehmen ist, sind der Datenstation zwei Prozesse zugeordnet, nämlich Prozeß A1 und Prozeß A2, die gemeinsam als Prozeßgruppe von Datenstation A bezeichnet werden. Datenstation B besitzt entsprechend zwei Prozesse, nämlich Prozeß B1 und Prozeß B2, die gemeinsam als Prozeßgruppe von Datenstation B bezeichnet werden. Wie der in Fig. 1 gezeigten Dateizugriffstabelle zu entnehmen ist, hat der Prozeß A1 für Datenstation A E/A- Dateien zum Zeichenpuffer des Bildschirmgeräts und zum Zeichenpuffer des Tastaturgeräts geöffnet, und entsprechend hat der Prozeß B1 E/A-Dateien für den Zeichenpuffer des Bildschirmgeräts und für den Zeichenpuffer des Tastaturgeräts von Datenstation B geöffnet. Bei Mehrplatzbetriebssystemen ist es durchaus üblich, daß ein Prozeß, der zur Prozeßgruppe einer ersten Datenstation gehört, Dateien öffnet, um die Kommunikation mit einer anderen Datenstation zu ermöglichen. Dies zeigt sich in Verbindung mit der Dateizugriffstabelle in Fig. 1, in der der Prozeß B1 eine Datei zum Zeichenpuffer DB(A) des Bildschirmgeräts und zum Zeichenpuffer KB(A) des Tastaturgeräts von Datenstation A geöffnet hat. Dadurch kann der Benutzer an der Datenstation B mit dem Benutzer an der Datenstation A kommunizieren.
Um den Zugriff von Prozessen auf die Gerätetreiber zu steuern, darf nur jenen Prozessen, die durch eine Zugriffsberechtigungstabelle berechtigt sind, erlaubt werden, mit einem bestimmten Gerätetreiber und dessen Zeichenpuffer zu kommunizieren. Wie aus Fig. 1 hervorgeht, besitzt der Bildschirm-Gerätetreiber DD(A) eine Zugriffsberechtigungstabelle AT(A), in der zwei Prozesse als berechtigt ausgewiesen sind, nämlich A1 und B1. Analog besitzt der Tastatur-Gerätetreiber KD(A) eine Zugriffsberechtigungstabelle AT(A'), die die Prozesse A1 und B1 dazu berechtigt, auf diesen Treiber und dessen Zeichenpuffer KB(A) zuzugreifen. Analog besitzt der Gerätetreiber DD(B) eine Zugriffsberechtigungstabelle AT(B), die nur eine Berechtigung für den Prozeß B1 enthält. Analog besitzt der Tastatur-Gerätetreiber KD(B) eine Zugriffsberechtigungstabelle AT(B), die nur eine Berechtigung für den Prozeß B1 enthält. Die Inhalte der Zugriffsberechtigungstabellen können nur durch einen privilegierten Prozeß wie z. B. der Init-Prozeß für die Einrichtung eines Sicherheitswegs geändert werden. Dagegen kann in einem ungesicherten Betriebsmodus auch der Benutzer auf die Zugriffsberechtigungstabelle zugreifen und diese verändern.
Die in Fig. 1 gezeigte Prozeßtabelle befindet sich im Speicher und unterhält jeweils einen aktualisierten Datensatz über den Zustand jedes im Speicher befindlichen Prozesses sowie die Benutzerkennung und die Bezeichnung der Datenstation des zur Ausführung dieses Prozesses berechtigten Benutzers. Wie Fig. 1 zu entnehmen ist, befinden sich alle vier Prozesse A1, A2, B1 und B2 in einem ausführbaren Zustand, was bedeutet, daß die Prozesse in einem Zeitscheiben-Multiprogramm-Betrieb des Betriebssystems bereit zur Ausführung sind und daß sie einen laufenden oder aktiven Status erhalten, wenn ihre Funktion vom Betriebssystem angewählt wird.
Das Sicherheitsproblem bei dem in Fig. 1 abgebildeten UNIX- artigen Betriebssystem besteht darin, daß der Benutzer an der Datenstation A nicht sicher sein kann, daß seine vertraulichen Dateneingaben von seiner Tastatur K(A) nicht vom Benutzer an der Datenstation B auf dessen Bildschirm D(B) belauscht werden, da der Benutzer an der Datenstation B ohne weiteres in einem seiner Prozesse in der Prozeßgruppe von Datenstation B Dateien geöffnet haben kann, welche die Zeichenpuffer DB(A) und KB(A) der Datenstation A überwachen können. Wie bereits erwähnt worden ist und wie die Dateizugriffstabelle in Fig. 1 zeigt, ist genau dies eingetreten.
Für den Benutzer an der Datenstation A ergibt sich als weiteres Sicherheitsproblem, daß an einen seiner eigenen Prozesse in der Prozeßgruppe von Datenstation A ein als Trojanisches Pferd arbeitendes Programm angehängt worden sein kann. Ein solches als Trojanisches Pferd arbeitendes Programm kann eine scheinbare sinnvolle Funktion besitzen, enthält jedoch zusätzliche, verborgene Funktionen, die heimlich die legitimierte Berechtigung des aufrufenden oder Host-Prozesses in der Prozeßgruppe von Datenstation A zum Nachteil für die Sicherheit von Datenstation A ausnutzen. Beispielsweise könnte das als Trojanisches Pferd arbeitende Programm eine "blinde Kopie" einer vertraulichen Datei erstellen, so daß ein unberechtigter Benutzer, nämlich der Autor des als Trojanisches Pferd arbeitenden Programms, die Sicherheit von Datenstation A knacken könnte.
Diese Sicherheitsprobleme bei UNIX-artigen Mehrplatzbetriebssystemen werden durch den Sicherheitswegmechanismus gelöst, dessen Merkmale und Funktionen in Fig. 2 dargestellt sind. Fig. 2 ist ein schematisches Diagramm des Datenprozessors in Fig. 1, der zusätzlich die Funktion der Sicherheitsanforderungstaste für die Errichtung eines erfindungsgemäßen Sicherheitswegs enthält. Wie Fig. 2 zu entnehmen ist, besitzt die Tastatur K(A) der Datenstation A eine erfindungsgemäße Sicherheitsanforderungstaste (SAK). Der Tastatur-Gerätetreiber KD(A) ist so abgeändert, daß er die durch die Sicherheitsanforderungstaste dargestellte eindeutige Zeichenkombination erkennt und ein Signal an den Generator für das Sicherheitsanforderungstasten-Signal ausgibt, wenn die Sicherheitsanforderungstaste gedrückt worden ist. Der Generator für das Sicherheitsanforderungstasten-Signal erzeugt das Sicherheitsanforderungstasten-Signal (SIGSAK), wenn er das Signal vom Tastatur-Gerätetreiber KD(A) empfängt. Der Generator für das Sicherheitsanforderungstasten-Signal ist ein Teil eines modifizierten Kernels für das UNIX-artige Betriebssystem.
Gemäß der Erfindung enthält der zu jedem im Speicher abgelegten Prozeß gehörige Benutzerblock eine Liste von Signal-Antworten auf UNIX-artige Signale, wobei zu diesen Signal-Antworten eine spezielle, für das Sicherheitsanforderungstastensignal (SIGSAK) vorgesehene Antwort gehört. Wenn der Generator für das Sicherheitsanforderungstasten-Signal ein SIGSAK-Signal an einen bestimmten Prozeß oder eine bestimmte Prozeßgruppe sendet, verlangt die gespeicherte Antwort im Benutzerblock dieses Prozessors, daß dieser Prozeß beendet wird. Der Generator für das Sicherheitsanforderungstasten-Signal kann an alle Prozesse in einer bestimmten Prozeßgruppe einer Datenstation ein SIGSAK- Signal senden, z. B. in Fig. 2 an die Prozesse A1 und A2 in der Prozeßgruppe von Datenstation A, wenn er vom Tastatur-Gerätetreiber KD(A) angezeigt bekommt, daß die Sicherheitsanforderungstaste auf der Tastatur K(A) gedrückt worden ist. Als Reaktion auf den Umstand, daß die Sicherheitsanforderungstaste von Datenstation A gedrückt worden ist, wird Schritt 1 ausgeführt, so daß alle Prozesse in der Prozeßgruppe von Datenstation A beendet werden und Schritt 1' in der Prozeßtabelle einen entsprechenden Statuseintrag vornimmt, der anzeigt, daß alle Prozesse von Datenstation A beendet sind.
Wenn der Generator für das Sicherheitsanforderungstasten-Signal ein SIGSAK ausgibt, wird dieses gemäß der Erfindung zudem in Schritt 2 an die Zugriffsberechtigungstabelle AT(A) und AT(A') geschickt, wobei es die Berechtigung der Prozesse A1 und A2 widerruft und an deren Stelle einsetzt, daß der Init-Prozeß der einzige Prozeß ist, der zum Zugriff auf die Gerätetreiber DD(A) und KD(A) und ihre entsprechenden Puffer DB(A) und KB(A) berechtigt ist.
Wenn der Generator für das Sicherheitsanforderungstasten-Signal ein SIGSAK ausgibt, wird dieses gemäß der Erfindung zudem durch Schritt 3 an die Dateizugriffstabelle gesendet und dient dazu, die Einträge aller Dateien in der Dateizugriffstabelle zu ändern, die mit den Zeichenpuffern DB(A) und KB(A) von Datenstation A verbunden sind. Somit werden die Einträge für Datenstation B, die zuvor die Verbindung zwischen Prozeß B1 und Datenstation A freigegeben hatten, widerrufen, so daß kein Prozeß in der Prozeßgruppe von Datenstation B über die Zeichenpuffer DB(A) und KB(A) mit der Datenstation A kommunizieren kann. Diesen Vorgang kann ein Befehl namens vhangup ausführen.
Der Kernel und der Init-Prozeß 1, der der Elternprozeß aller anderen Prozesse im System ist, bleiben als gesicherte Prozesse erhalten. Daher werden gemäß der Erfindung die Einträge in der Dateizugriffstabelle so geändert, daß nur der Init-Prozeß in der Lage ist, über die Dateizugriffstabelle mit den Zeichenpuffern DB(A) und KB(A) von Datenstation A in Verbindung zu treten. Somit ist in dem in Fig. 2 gezeigten Zustand außer dem Init- Prozeß 1 kein anderer Prozeß im Speicher des Datenprozessors in der Lage, Verbindung zur Datenstation A aufzunehmen.
Fig. 3 ist ein schematisches Diagramm des Datenprozessors in Fig. 2, die die Einrichtung des Sicherheitswegs zu einer gesicherten Shell zeigt. Der Kernel enthält erfindungsgemäß einen gesicherten Shell-Prozeß TSH, der entweder als Teil des Kernels vom Plattenspeicher eingelesen wird oder alternativ als separate gesicherte Datei auf Befehl des Kernels vom Plattenspeicher eingelesen wird. Bei UNIX-artigen Betriebssystem erzeugt der Systemaufruf "fork" zwei neue, identische Kopien eines Prozesses. Eine Kopie wird Eltern, die andere Kind genannt. Sämtliche Teile des Abbilds des Elternprozesses einschließlich offener Dateien werden vom Kind geerbt. Der Prozeß "fork" besitzt eigene Daten- und Stack- oder Benutzerblockbereiche. Die einzigen Betriebsmittel, die sich Eltern und Kind teilen, sind die Dateien, die geöffnet wurden, als der Elternprozeß dem Systemaufruf "fork" unterzogen wurde. Der Init-Prozeß führt in Schritt 4 in Fig. 3 erfindungsgemäß einen Systemaufruf "fork" aus, der einen Kindprozeß erzeugt, der beinahe eine identische Kopie des Init- Prozesses ist. Genau dieser Kindprozeß überlagert sich selbst mit einem Abbild des gesicherten Shell-Prozesses TSH. Die Überlagerung erfolgt durch einen weiteren UNIX-artigen Systemaufruf, den Systemaufruf "exec". Der Systemaufruf "exec" überlagert den laufenden Prozeß mit einem neuen Programm und startet die Ausführung des Programms an dessen Eingangspunkt. Die Prozeßkennung wird durch den Systemaufruf "exec" nicht verändert. Im Erfolgsfall kehrt dieser Aufruf nicht zurück, und das Abbild des aufrufenden Programms ist verloren. Daher führt gemäß der Erfindung das Kind des Init-Prozesses einen Systemaufruf "exec" durch, der den gesicherten Shell-Prozeß TSH aufruft, der vom (oder mit dem) Kernel vom Plattenspeicher eingelesen wurde. Da die gesicherte Shell TSH der Kindprozeß von init ist, besitzt die gesicherte Shell TSH in den Zugriffsberechtigungstabellen AT(A) und AT(A') die Berechtigung zum Zugriff auf die Gerätetreiber DD(A) und KD(A). Da alle anderen zur Prozeßgruppe von Datenstation A gehörenden Prozesse beendet und aus dem Speicher entfernt worden sind und weil darüberhinaus die die Dateizugriffstabelle so geändert worden ist, daß außer dem gesicherten Shell-Prozeß TSH kein anderer Prozeß eine Verbindung zu den Zeichenpuffern der Datenstation A aufbauen kann, besteht nun ein Sicherheitsweg zwischen der Datenstation A und dem gesicherten Shell-Prozeß TSH.
Der gesicherte Shell-Prozeß TSH kann eine Vielzahl von Befehlen, Funktion und Hilfsprogrammen enthalten, die von der Datenstation A auf vollständig sichere Weise aufgerufen werden können. Ein Beispiel dafür ist eine sichere Anmeldefunktion, bei der der Benutzer an Datenstation A seine Kennung anmelden und sein Kennwort eingeben kann, ohne Gefahr zu laufen, daß ein unberechtigter Benutzer sein Kennwort erlauscht.
Auf diese Weise ermöglicht die Erfindung des Sicherheitswegmechanismus die sichere Kommunikation zwischen der Datenstation eines Benutzers und gesicherten Prozessen im Datenprozessor, ohne daß dabei die laufenden Datenverarbeitungsvorgänge durch andere, an denselben Datenprozessor angeschlossene Datenstationen negativ beeinträchtigt werden.
Das spezielle Ausführungsbeispiel der hier offenbarten Erfindung wird auf das Betriebssystem AIX angewendet. Daher liefert die folgende Erörterung einige Hintergrundinformationen über die Betriebsprinzipien des Betriebssystems AIX, die dem Leser beim Verständnis der hier offenbarten und beanspruchten Erfindung helfen. Für weitere Informationen über das Betriebssystem AIX wird der Leser auf die zuvor zitierte IBM Veröffentlichung "AIX Operating System Technical Reference" verwiesen.

Erörterung des Hintergrunds des Betriebssystems AIX

Da das Betriebssystem AIX und andere UNIx-artige Betriebssysteme eine Reihe spezieller Begriffe verwenden, werden für einige dieser Begriffe folgende Definitionen gegeben.
Prozeß: Eine Folge von Aktionen, die erforderlich sind, um ein gewünschtes Ergebnis zu erreichen, wie eine Aktivität innerhalb des Systems, die durch Eingabe eines Befehls, Ausführung eines Shell-Programms oder durch Aufruf von einem anderen Prozeß aus eingeleitet wird.
Kennwort: Eine Zeichenkette, die zusammen mit der Benutzerkennung eingegeben werden muß, damit ein Benutzer sich beim System anmelden kann.
Betriebssystem: Software, die den Ablauf von Programmen steuert. Zusätzlich kann ein Betriebssystem Dienste wie Zuweisung der Betriebsmittel, Prozeßverwaltung, Steuerung der Ein- und Ausgabe und Datenverwaltung zur Verfügung stellen.
Kernel: In UNIX-artigen Betriebssystemen implementiert der Kernel die Schnittstelle für Systemaufrufe.
Init: Nachdem der Kernel die grundlegende Initialisierung abgeschlossen hat, startet er einen Prozeß, der Vorfahre aller anderen Prozesse im System ist und init genannt wird. Der Prozeß init ist ein Programm, das den Zustand steuert, in dem das System betrieben wird; normalerweise ist dies entweder der Mehrplatzmodus oder der Wartungsmodus.
Getty: Der Prozeß init führt den Befehl getty für jeden Systemanschluß durch. Seine Hauptfunktion ist, die Konfigurationsdaten des betreffenden Anschlusses festzulegen.
Login: Das Programm login meldet den Benutzer beim System an, überprüft das Kennwort des Benutzers, nimmt die entsprechenden Protokolleinträge vor, richtet die Verarbeitungsumgebung ein und ruft den Befehls-Interpreter auf, der in der Kennwortdatei angegeben ist; dies ist üblicherweise das Programm shell (SH).
Shell (SH): Der Befehl "shell" ist ein Interpreter für Systembefehle und eine Programmiersprache. Es handelt sich dabei um ein gewöhnliches Benutzerprogramm, das über die Tastatur eingegebene Befehle liest und dafür sorgt, daß sie ausgeführt werden.
Fork: Der Systemaufruf fork erzeugt einen neuen Prozeß, der als Kindprozeß bezeichnet wird und eine genaue Kopie des aufrufenden Prozesses (des Elternprozesses) ist. Der Kindprozeß erbt die meisten Eigenschaften des Elternprozesses.
Exec: Der Systemaufruf exec führt innerhalb des aufrufenden Prozesses ein neues Programm aus. Exec erzeugt kein neues Programm, sondern überlagert das derzeitige Programm mit einem neuen, das als neues Prozeßabbild bezeichnet wird. Die Datei des neuen Prozeßabbildes kann eine ausführbare Binärdatei, eine ausführbare Textdatei, die eine shell-Prozedur enthält, oder eine Datei sein, die den Namen einer ausführbaren Binärdatei oder einer Shell-Prozedur enthält, die ablaufen soll.
Signal: Signale sorgen für die Kommunikation mit einem aktiven Prozeß, wobei eine einzelne Menge von Ereignissen ausgelöst wird und die aktuelle Prozeßumgebung gesichert und eine neue erzeugt wird. Ein Signal ist ein Ereignis, das den normalen Ablauf eines Prozesses unterbricht, und kann eine Unterroutine zur Behandlung von Signalen angeben,-, die beim Auftreten eines Signals aufgerufen werden kann.
Die RT PC Systemsoftware ist in Ebenen aufgebaut: der Virtual Resource Manager (VRM), das Virtual Machine Interface (VMI) und das Betriebssystem AIX. Der Virtual Resource Manager erweitert die Hardwarefunktionen des Prozessors und der Speicherverwaltung, um ein hohes Maß an Unterstützung für Hardware-Geräte für das Betriebssystem in einer virtuellen Maschinenumgebung zur Verfügung zu stellen. Das Virtual Machine Interface ist die Protokolleingrenzung zwischen dem Betriebssystem und dem Virtual Machine Manager. Gemäß der Definition durch den VRM hat eine virtuelle Maschine eine hochentwickelte, jedoch physische maschinenartige Schnittstelle.
Der Virtual Resource Manager stellt eine virtuelle Maschinenumgebung zur Verfügung, die im wesentlichen dieselben Merkmale wie die physische Maschine besitzt. Virtuelle Maschinen arbeiten im Fehlerstatus (unprivilegierter Status) und spiegeln den Vorrangstatus (privilegierter Status) der physischen Maschine nicht direkt wider. Diese Funktionen werden vom Virtual Resource Manager wahrgenommen.
Eine virtuelle Maschine besitzt zwei Schutzstatus, nämlich den Status Benutzer (unprivilegiert) und den Status Betriebssystem (privilegiert). Der Status Betriebssystem und der Status AIX- Kernel sind synonym. Jedesmal, wenn die virtuelle Maschine Anweisungen ausführt (entweder im Benutzerstatus oder im Betriebssystemstatus), befindet sich der Prozessor in Wirklichkeit im Fehlerstatus. Nur der Virtual Resource Manager (einschließlich durch das Betriebssystem AIX im VRM installierter Code) kann im echten Vorrangstatus arbeiten.
Im Benutzerstatus kann eine virtuelle Maschine beliebige Fehlerstatusanweisungen erteilen. Eine der Anweisungen, die der virtuellen Maschine zur Verfügung stehen, ist die Anweisung SVC (supervisor call = Supervisoraufruf). Die Anweisung SVC enthält ein 16-Bit-Feld, das die gewünschte Supervisor-Funktion anzeigt. Das höherwertige Bit dieses Felds bestimmt, ob der Ruf an den Virtual Resource Manager (Bit gesetzt) oder an den Supervisor der virtuellen Maschine (Bit gelöscht), das Betriebssystem AIX, erfolgen soll. Der VRM akzeptiert keine Aufrufe an den Virtual Resource Manager aus dem Benutzerstatus der virtuellen Maschine. Der Übergang vom Benutzerstatus der virtuellen Maschine in den Betriebssystemstatus erfolgt, indem eine in der virtuellen Maschine laufende Anwendung dem Supervisor der virtuellen Maschine einen Systemaufruf vom Typ SVC erteilt.
Eine virtuelle Maschine geht entweder aufgrund eines von einem Prozeß mit Benutzerstatus an sie gesendeten SVC oder aufgrund einer vom Virtual Resource Manager an sie gesendeten virtuellen Unterbrechung in den Betriebssystemzustand. Im Betriebssystemstatus kann die virtuelle Maschine alle Anweisungen verwenden, die im Benutzerzustand verfügbar sind. Außerdem kann die virtuelle Maschine im Betriebssystemstatus SVCs an den Virtual Resource Manager erteilen.
Da jede virtuelle Maschine einen separaten Speicherbereich besitzt, der an der Position 0 beginnt, gelten diese Speicherpositionen für alle virtuellen Maschinen. Speicherpositionen von virtuellen Maschinen zwischen 0xc0 und 0x2dc sind für die Kommunikation zwischen der virtuellen Maschine und dem Virtual Resource Manager reserviert. Diese Positionen werden für im Speicher abgelegte Zeitgeberwerte, Program Status Blocks (PSBs) für SVCs und Unterbrechungen sowie für diverse andere Werte verwendet.
Für jede Prioritätsunterbrechungsebene, jeden Programmfehler, jede Maschinenkommunikation und jeden SVC gibt es einen separaten PSB. Der PSB enthält das Instruction Address Register (IAR) für den Unterbrechungspunkt, die Unterbrechungssteuerung und Statusfelder, die Definition von Unterebenen und vier Statusworte und für die Unterbrechung spezifische Daten.
Der Virtual Resource Manager bietet Unterstützung für den Seitenwechsel des virtuellen Speichers für das auf einer virtuellen Maschine laufende Betriebssystem. AIX wurde so entwickelt, daß die durch den VRM gebotene Unterstützung von virtuellem Speicher vorteilhaft genutzt werden kann. Die Unterstützung von virtuellem Speicher durch VRM sorgt dafür, daß die Hardware-Speicherverwaltungsfunktionen für AIX verfügbar sind, während sie es von den Details des Seitenwechselvorgangs (Seitenersetzungsalgorithmus, Verwaltung von Seitenwechsel-E/A und so weiter) befreit. Die Schnittstelle zum virtuellen Speicher besteht aus einer Reihe von SVCs, Programmfehlerunterbrechungen (Adressierung und Schutzausnahmen) und Maschinenkommunikationsunterbrechungen (Auftreten und Löschen von Seitenfehlern). Das Speicher-Grundmodell für die virtuelle Maschine stellt sich in Form von Segmenten dar.
SVCs stehen zur Verfügung, um Segmente zu erstellen, Segmente zu kopieren, Segmente zu zerstören, die Eigenschaften von Segmenten zu verändern (Beispiele dafür sind das Ändern von Größe und Schutzstatus, um Segmentkennungen in Segmentregister der Hardware-Speicherverwaltung zu laden, usw.). Auch eine SVC-Schnittstelle steht zur Verfügung, um AIX die Möglichkeit zu geben, den Seitenersetzungsalgorithmus des Virtual Resource Managers zu beeinflussen. Über diese Schnittstelle unterrichtet AIX den Virtual Resource Manager darüber, daß bestimmte Seiten aus dem Hauptspeicher gelöscht werden sollten, daß bestimmte Seiten im Hauptspeicher festgehalten werden sollten oder daß zuvor festgehaltene Seiten freigegeben werden sollten.
Das Betriebssystem AIX ist eine Erweiterung des UNIX Systems V (TM). Zu den Erweiterungen zählen die Einrichtungen, die virtuellen Speicher verwenden. AIX läuft auf einer virtuellen Maschine auf dem Virtual Resource Manager. Der Kernel ist das Herzstück des Betriebssystems AIX für virtuelle Maschinen und somit auch der Verwalter der verschiedenen Geräte und Betriebsmittel, aus denen die virtuelle Maschine besteht, in der er sich befindet. Im wesentlichen ist er der zentrale Steuerungspunkt für alle virtuellen Maschinenaktivitäten und die virtuellen Maschinenbetriebsmittel.
Die Interna von AIX wurden abgeändert und erweitert, damit es auf einer virtuellen Maschine laufen kann, eine erweiterte Prozeßumgebung zur Verfügung stellen kann und ein brauchbares und stabiles Dateisystem zur Verfügung stellen kann. Die Schnittstellen zu Systemaufrufen und Unterprogrammen ermöglichen vielen für UNIX-kompatible Systeme geschriebenen Programmen und Hilfsprogrammen den Betrieb unter AIX.
Der Kernel führt folgende Hauptfunktionen durch.
Dateisystemverwaltung:
- Datei: Öffnen, Schließen, Lesen, Schreiben, Besitzerwechsel, Abfragen/Ändern von Statistiken, Suchen
- Dateisystem: mount, umount, Statistik abfragen
- Verzeichnis: Arbeitsverzeichnis wechseln, Stammverzeichnis wechseln, Verzeichnis erstellen, mit einer Datei verknüpfen, von einer Datei ablösen
- Sicherheit: auf Berechtigungen zugreifen.
Prozeßverwaltung:
- Beginnen und Beenden: Verzweigung eines Prozesses, diesen Prozeß beenden, einen weiteren Prozeß löschen, eine Prozeßgruppe löschen
- Prozeßgruppe setzen
- Informationen: Benutzer freigeben/sperren, Kennung abfragen (Prozeß, Eltern, Gruppe), Zeiten abfragen
- Vorrangsvorschlag
- Warten auf Beendigung eines Kindprozesses
- Daten, Text oder Stack im Speicher festhalten
- Signale: Signale freigeben/sperren, Signale auf Benutzer- Routinen lenken, auf Signal warten
- Semaphore: Semaphore erstellen, Semaphorkennung abfragen, Semaphorfunktionen durchführen, Semaphor löschen.
Speicherverwaltung:
- privater Speicher: Vergrößern, Verkleinern
- gemeinsamer Speicher: Erstellen, Anfügen, Löschen.
Zeitverwaltung:
- Zeit setzen
- Zeit abfragen.
Programmverwaltung:
- Neues Programm ausführen
- Ein Programm im Speicher festhalten.
Betriebsmittelverwaltung:
- Benutzer- und Gruppenkennungen setzen und abfragen
- Grenzen für Benutzer setzen und abfragen.
Bevor der Kernel ausgeführt werden kann, muß er zuerst in Segment 0 der virtuellen Maschine geladen werden. Das Urladeprogramm ist dafür zuständig, den Kernel im Stammverzeichnis des Dateisystems zu finden, ihn in den Speicher einzulesen und ihm schließlich die Kontrolle zu übergeben.
Das Urladeprogramm durchsucht das Stammverzeichnis des Dateisystems nach der Datei "/unix", liest deren Text- und Datensegment in den Speicher ein und erweitert das Segment. Das Urladeprogramm entfernt sich selbst, verschiebt den Kernel, damit er bei Adresse 0 startet, und übergibt dann dem Kernel an dessen Starteingangspunkt die Kontrolle, womit der Urladeprozeß abgeschlossen ist.
Als "Prozeß" wird der aktuelle Zustand eines laufenden Programms bezeichnet. Dazu gehören ein Abbild des Speichers (der logische Aufbau seiner Teile im Speicher), der Programmtext, die Programmdaten, benutzte Variablen, allgemeine Registerwerte, der Status geöffneter, verwendeter Dateien und das aktuelle Verzeichnis. Die im Rahmen des Prozesses ausgeführten Programme können entweder Betriebssystemprogramme oder Benutzerprogramme sein. Ein Prozeß muß aktiv sein, um vom Kernel auszuführende Dienste anzufordern. Wenn nötig, werden Prozesse in den Speicher eingelagert bzw. aus ihm ausgelagert. Aktuell nicht laufende Prozesse können auf Wunsch aus dem Speicher auf Platte ausgelagert werden.
Ein und derselbe Prozeß kann entweder im "Benutzer" -Modus oder im "Kernel"-Modus vorliegen. Normalerweise wird ein Benutzerprogramm während seiner Ausführung Benutzerprozeß genannt, und man geht davon aus, daß es sich im "Benutzermodus" befindet. Wenn der Prozeß eine Systemfunktion anfordert, ruft er das System als Unterprogramm auf. Ein Prozeß im Benutzermodus verwendet Systemaufrufe zum Zugriff auf Systembetriebsmittel. Dies wird manchmal auch als Kernel-Aufruf bezeichnet. Wenn der Benutzerprozeß einen Systemaufruf abgibt, schaltet die Umgebung vom Benutzer- in den Kernel-Modus. Das System führt den gleichen Prozeß aus. Der Unterschied besteht darin, daß der für den Benutzerprozeß laufende Code in diesem Fall Code des Kernels ist. Der Prozeß befindet sich nun im "Kernel-Modus". Ein Prozeß im Kernel-Modus besitzt die volle Kontrolle über das System. Wenn der Kernel den angeforderten Dienst abgeschlossen hat, gibt er normalerweise die Kontrolle an den Benutzermodus des Prozesses zurück. Ein Prozeß im Benutzermodus kann jederzeit abgebrochen werden. Im Gegensatz dazu kann ein Prozeß im Kernel-Modus normalerweise nicht abgebrochen werden. Normalerweise läuft ein Prozeß im Kernel-Modus, bis er die Kontrolle über den Prozessor von sich aus abgibt.
Mehrere Mechanismen können ein Umschalten vom Benutzermodus in den Kernel-Modus fordern. Ein Mechanismus, der ein Umschalten bewirkt, ist der Systemzeitgeber. Der Systemzeitgeber unterbricht den Prozessor regelmäßig in festen Zeitabständen pro Sekunde. Eine Unterbrechung ist ein Signal, das den Prozessor zu einer speziellen Softwareroutine umleitet. Während der Dienstroutine für den Systemzeitgeber überprüft der Kernel die Priorität der Prozesse auf einen möglichen Prozeßwechsel. Der Ablaufplaner des Systems führt die grundlegende Zeitscheibeneinteilung durch, damit der Prozessor von vielen Benutzern gemeinsam benutzt werden kann.
Auch E/A-Dienstanforderungen bewirken ein Umschalten. Unterbrechungsroutinen markieren die E/A-Vorgänge als beendet. Diese Routinen starten den nächsten E/A-Vorgang in der Gerätewarteschlange, markieren alle auf den Dienst wartenden Programme als ausführungsbereit und setzen eine Marke, um erforderlichenfalls bei der Rückkehr vom Kernel-Modus in den Benutzermodus einen Prozeßwechsel auszulösen.
Der Virtual Resource Manager (VRM) stellt dem Betriebssystem eine Speicherverwaltung zur Verfügung. Der VRM stattet das Betriebssystem mit umgelagertem virtuellem Speicher aus. Fehlerseitenbedingungen können das Betriebssystem unterbrechen, so daß es zu einer anderen Aufgabe umschalten kann. Virtuelle Speicherfunktionen werden hauptsächlich von SVCs vom Betriebssystem zum VRM gesteuert; dabei werden je nach Bedarf Unterbrechungen verwendet.
Wenn ein Prozeß entweder im Benutzermodus oder im Kernel-Modus ausgeführt wird, können Teile dieses Prozesses adressiert werden. Der 32 Bit breite virtuelle Adreßraum ist in 16 Segmente unterteilt. Jedes Segment ist 2**28 Byte groß. Die Segmentregister bieten Zugriff auf den segmentierten virtuellen Speicher für die virtuelle Maschine. Die Hardware des virtuellen Speichers erlaubt maximal 16 gleichzeitige Segmentzugriffe. Die Implementierung als RT PC schränkt den Benutzermodus auf 14 gleichzeitige Segmentzugriffe ein. Einem Prozeß im Kernel-Modus ist es dagegen erlaubt, auf alle Segmente, auf die die virtuelle Maschine zugreifen kann, gleichzeitig zuzugreifen. Die Segmentregister stellen mehrere Mechanismen für den Schutz der Speichersegmente zur Verfügung: durch das selektive Laden von Segmentadressen in Segmentregister und durch das Setzen des Seitenschutzbits in jedem Segmentregister. Die Schutzeinstellungen stellen einen Mechanismus zum Aufruf von Lese- und/oder Schreibschutz in beiden Maschinenstatus zur Verfügung.
Jedes Segmentregister adressiert ein logisches RT PC Programmsegment teilweise oder vollständig. Alle Adressen sind virtuelle, volle 32 Bit breite Adressen, wobei die Segmentnummer die vier Bit ganz links belegt. Die Segmentregister sind ein Teil des Prozeßabbilds und werden daher bei jeder Zuteilung umgeschaltet. Der Kernel wird durch das Segmentregister 0 adressiert. Dazu gehören der Programmtext des Kernels, Daten und alle E/A-Puffer. Diese Adressierung ist fest. Das Textsegment des Benutzerprogramms wird durch das Segmentregister 1 adressiert, und das Datensegment des Benutzerprogramms wird durch das Segmentregister 2 adressiert. Der Stack des Benutzerprozesses und die Benutzerstruktur (u.block) werden durch das Segmentregister 3 adressiert. Der Stack des Benutzerprozesses wächst von der höchsten zur niedrigsten Segmentadresse (von oben nach unten). Die Segmentregister 4 bis 13 werden für die Bearbeitung von gemeinsam benutzten Daten in Benutzerprogrammen verwendet. RT PC stellt eine Programmierschnittstelle zur Bearbeitung dieser Register mittels Systemaufrufen an gemeinsam benutzte Segmenten zur Verfügung.
Der VRM reserviert das Segmentregister 14 für direkten Speicherzugriff (DMA, direct memory access), und Segmentregister 15 ist für E/A über den Bus reserviert. Dieses Register wird zur Adressierung des E/A-Kommunikationskanals (IOCC, I/O communication channel), des Gleitkomma-Adapters (FPA, floating point adapter) und von speicheradressierten Adaptern verwendet.
Ein Prozeß im Benutzermodus greift während seiner Ausführung auf folgende logischen Bereiche zu. Diese Bereiche dienen zur Speicherung von Informationen, die vom Prozeß verwendet werden.
Textsegment: Dieses Segment wird durch Segmentregister 1 adressiert und kann von einem Prozeß im Benutzermodus adressiert werden. Das "Text"-Segment belegt die niedrigen Adressen im virtuellen Adreßraum eines Prozesses. Dieses Segment enthält normalerweise den Code des gerade ausgeführten Benutzerprogramms. Die Informationen in diesem Segment stammen vom Lademodul, das einen Systemaufruf "exec" ausgeführt hat. (Der Systemaufruf "exec" wird später kurz erläutert). Während der Ausführung ist dieses Segment schreibgeschützt, und alle Prozesse, die den gleichen Code ausführen, teilen sich eine einzige Kopie.
Datensegment: Dieses Segment wird durch Segmentregister 2 adressiert und kann von einem Prozeß im Benutzermodus adressiert werden. Das "Daten"-Segment eines Benutzerprozesses beginnt an der logischen Grenze über dem Textsegment. Der Prozeß kann auf dieses Segment zum Lesen und zum Schreiben zugreifen. Dieses Segment wird nicht gemeinsam mit anderen Prozessen benutzt; seine Größe kann erweitert werden. Dieses Segment enthält einen initialisierten Teil, der für Datenvariablen wie z. B. Felder verwendet wird.
Stack-Segment: Dieses Segment wird durch Segmentregister 3 adressiert und kann von einem Prozeß im Benutzermodus teilweise adressiert werden. Dieses Segment enthält den Stack des Benutzerprozesses und die Benutzerstruktur ("u.block"). Die Benutzerstruktur kann nicht von einem Prozeß im Benutzermodus adressiert werden. Dieses Segment eines Benutzerprozesses beginnt am oberen Adreßende des virtuellen Adreßraums des Prozesses und nimmt je nach Bedarf in Richtung des Datensegments automatisch an Größe zu. Dieses Segment enthält den Laufzeit-Stack eines Programms, und Benutzerprogramme können in es hineinschreiben. Der Prozeß benutzt den oberen Teil dieses Segments, um E/A-Informationen an den Kernel weiterzuleiten.
Außer den Text-, Daten- und Stack-Segmenten, die jeder Prozeß benutzt, kann ein Prozeß Segmente, auf die andere Prozesse Zugriff haben, erzeugen und/oder sich an diese anhängen. Für die Verwendung gemeinsam benutzter Segmente steht eine Reihe von Systemaufrufen zur Verfügung. Wird ein gemeinsam benutztes Segment erstellt oder angefügt, wird es Teil des Adreßraums des anfordernden Prozesses.
Gemeinsam benutzte Segmente können entweder in einem schreibgeschützten Modus oder in einem Schreib/Lese-Modus benutzt werden. Es ist zu beachten, daß es beim Zugriff von zwei oder mehr Prozessen auf das gleiche gemeinsam benutzte Segment keine implizite Unterstützung für die Serialisierung gibt. Wenn ein Prozeß einen bestimmten Bereich eines gemeinsam benutzten Segments liest, dann sind die zwei (oder mehr) Prozesse dafür verantwortlich, ihren Zugriff auf den gemeinsam benutzten Bereich zu koordinieren.
Neben der gemeinsamen Benutzung von Segmenten stehen Systemaufrufe zur Verfügung, die es einem Prozeß gestatten, eine gewöhnliche Datei in einem beliebigen montierten Dateisystem mit dem Adreßbereich eines gemeinsam benutzten Segments logisch zu überlagern. Der Zugriff auf die Datei kann dann durch den Zugriff auf das Segment erfolgen. Das Segment kann von anderen Prozessen gemeinsam oder von einem einzigen Prozeß alleine benutzt werden. Es gibt drei Modi, eine Datei mit einem Segment zu adressieren. Dies sind Schreiben/Lesen, Schreibschutz und Kopieren beim Schreiben.
Bei einer zum Lesen und Schreiben adressierter Datei können sich Lade- und Speichervorgänge im Segment wie Lese- und Schreibvorgänge in der entsprechenden Datei verhalten. Falls ein Prozeß den Segmentteil hinter dem logischen Dateiende liest, dann liest der Prozeß Nullen. Falls der Prozeß in den Segmentteil hinter dem Dateiende schreibt, wird die Datei erweitert.
Wenn eine Datei als schreibgeschützt adressiert wird, kann sie nur gelesen werden. Ein eventueller Versuch, durch Speichern in das Segment in die Datei zu schreiben, signalisiert dem Prozeß einen Fehler. Wie beim Schreib/Lese-Modus liest ein Prozeß, der auf den Segmentteil hinter dem Dateiende zugreift, nur Nullen.
Auch bei einer im Modus Kopieren beim Schreiben adressierten Datei können sich die Lade- und Speichervorgänge im Segment wie Schreib- und Lesevorgänge in der entsprechenden Datei verhalten, mit der Ausnahme, daß Schreibvorgänge temporär sind. Das heißt, daß bei eventuellem Speichern in ein im Modus Kopieren beim Schreiben adressiertes Segment das Segment, nicht jedoch die entsprechende Datei geändert wird. Der Systemaufruf "fsync" schreibt die geänderten Bereiche des Segments in die entsprechende Datei, wodurch die adressierte Datei zu einer exakten Kopie des Segments wird. Wenn dieser Systemaufruf nicht erfolgt, wird die Datei nie geändert, was es einem Prozeß ermöglicht, an einer Datei vorgenommene Änderungen rückgängig zu machen, falls er feststellt, daß die Änderungen unnötig sind.
Ein Prozeß im Kernel-Modus kann folgende Bereiche adressieren. Wenn nicht anders vermerkt, werden diese Bereiche durch Register 0 adressiert. Daten, die direkt zu einem Prozeß gehören, werden mit dem Prozeß aus dem Speicher ausgelagert. Diese Bereiche enthalten all die Informationen über einen Prozeß, die der Kernel benötigt, wenn der Prozeß aktiv ist. Die vier Bereiche sind:
Text: Dieser Bereich enthält Programmcode des Kernels, der gerade ausgeführt wird. Ein Benutzerprozeß kann ihn nur lesen.
Globale Daten: Diese Daten können von einem beliebigem Prozeß adressiert werden, solange er sich im Kernel-Modus befindet. Sie enthalten vom Kernel verwaltete Tabellen wie z. B. die Tabelle der offenen Dateien und die Prozeßtabelle sowie andere Daten wie z. B. Pufferzeiger.
Benutzerprozeßdaten: Dieser Bereich wird mitunter "Benutzerstruktur", "Benutzerbereich", "u.area", "Benutzerblock" oder "u.block" genannt. Es ist ein Teil des Stack-Segments des Benutzerprozesses. Dieser Bereich wird mit dem Prozeß ein- bzw. ausgelagert. Er enthält Informationen über den Prozeß wie z. B. das aktuelle Verzeichnis von Dateien, die der Prozeß geöffnet hat, oder Eingaben und/oder Ausgaben (E/A) im Kernel-Modus. Diese Informationen belegen den oberen Teil des Stack-Segments.
Stack: Dieser Bereich wird mit dem Benutzerprozeß ein- bzw. ausgelagert. Der Kernel verwaltet für jeden Prozeß einen Stack. Er puffert die Informationen über den Prozeß wie z. B. die Aufrufkette und lokale Variablen, die der Kernel für den Benutzerprozeß verwendet.
Der größte Teil der Prozeßverwaltung durch den Kernel besteht in der Suche in Tabellen und deren Änderung. Der Kernel verwaltet mehrere Tabellen, um die Ausführung vieler Prozesse zu koordinieren. Fig. 4 zeigt die vom Kernel zur Verwaltung von Prozessen verwalteten Tabellen.
Die "Prozeßtabelle" enthält für jeden eingerichteten Prozeß einen Eintrag. Diese Tabelle enthält die Daten, die benötigt werden, wenn der Prozeß nicht gerade läuft. Diese Tabelle befindet sich stets im Speicher; daher kann der Kernel Ereignisse des Prozesses verwalten. Jeder Tabelleneintrag gibt Einzelheiten des Status eines Prozesses wider. Die Statusinformation enthält die Segmentkennungen des Prozesses, die Kennnummer des Prozesses und die Kennung des Benutzers, der den Prozeß ablaufen läßt. Für jeden Prozeß gibt es nur eine Tabelle; daher wird die Zahl der Prozesse, die eingerichtet werden können, durch die Größe der Tabelle bestimmt, die als Konfigurationsparameter "procs" in der Datei "/etc/master" angegeben ist. Die Einrichtung eines Prozesses bewirkt einen Eintrag in der Prozeßtabelle, während die Beendigung eines Prozesses einen Eintrag in der Tabelle freigibt. Ein Tabelleneintrag ist für einen Prozeß mit der Berechtigung "Superuser" reserviert. Ein Prozeß wird dann als "Superuser"- Prozeß erkannt und mit Sonderrechten versehen, wenn sein Benutzerkennung für den Betrieb gleich O ist.
Jeder Prozeß besitzt eine eigene Kopie der Variablensegmente des Prozesses, während das Textsegment gemeinsam benutzt werden kann. Die gemeinsame Nutzung von Programmtext erlaubt eine effektivere Speichernutzung. Wenn Prozesse Textsegmente gemeinsam nutzen, verwaltet das System eine "Texttabelle". Diese Tabelle dient dazu, das gemeinsam genutzte Textsegment für jeden Prozeß, der ein Textsegment mitbenutzt (zum Beispiel können ein Eltern- und ein Kindprozeß nach einer Aufspaltung gemeinsam Text benutzen), zu registrieren. Der Aufbau dieser Tabelle findet sich bei "/usr/include/sys/text.h" im Dateisystem. Ein Eintrag in der Texttabelle enthält die Segmentkennung des Textsegments und die Anzahl der Prozesse, die sich diesen Eintrag teilen. Wird die Anzahl auf 0 verringert, wird der Eintrag zusammen mit dem Prozeß freigegeben. Der erste Prozeß, der ein gemeinsam genutztes Textsegment ausführt, bewirkt, daß ein Tabelleneintrag zugeteilt wird und daß das Segment eingerichtet wird. Ein zweiter Prozeß, der ein bereits bestehendes Textsegment ausführt, bewirkt, daß die Anzahl in der Texttabelle erhöht wird.
Die "Benutzerstruktur" (auch Datenbereich des Benutzerprozesses oder Benutzerblock genannt) enthält Informationen, auf die während der Prozeßausführung ein Zugriff möglich sein muß. Jedem aktiven Prozeß wird eine Benutzerstruktur zugeordnet. Die Kernel-Routinen können direkt auf die Benutzerstruktur zugreifen. Dieser Block enthält Informationen wie z. B. Benutzer- und Gruppen-Kennummer zur Ermittlung von Dateizugriffsprivilegien, Zeiger auf Systemdateitabelle für die vom Prozeß geöffneten Dateien, einen Zeiger auf den Tabelleneintrag am i-Knoten und eine Liste mit Reaktionen auf verschiedene Signale. Die Benutzerstruktur ist Teil des Benutzerstacksegments.
Das "Benutzerdatensegment" enthält Benutzerdaten. Die Daten bestehen aus initialisierten Datenvariablen. Ein Zeiger auf dieses Segment findet sich im Eintrag in der Prozeßtabelle. Das Benutzertextsegment enthält Programmcode. Ein Zeiger auf dieses Segment findet sich in der Prozeßtabelle und, falls es gemeinsam genutzt wird, in der Texttabelle.
Einrichtung und Ausführung: Wird die Datei "/unix" gefunden, dann wird sie in das Segment 0 geladen und ausgeführt. Sie initialisiert zunächst Plattendatenstrukturen wie z. B. die Liste freier Blöcke, die E/A-Puffergruppe, den Bereich der Zeichenpuffer und die Liste verfügbarer i-Knoten. Ist die Initialisierung abgeschlossen, beginnt der Kernel mit dem Aufbau des ersten Prozesses (Prozeß 0), auch "Scheduler" (Ablaufplaner), vgl. Fig. 5, genannt. Der Scheduler wird nicht wie andere Prozesse vom Systemaufruf "fork" (Beschreibung folgt) eingerichtet und enthält auch nicht alle Teile eines Prozesses. Er ist ein einzigartiger Prozeß, der nur eine vom Kernel zu verwendende Datenstruktur enthält. Der Prozeß 0 ist der erste Eintrag in der Prozeßtabelle und nur aktiv, wenn der Prozessor im Kernel-Modus arbeitet.
Der Prozeß 0 erzeugt einen weiteren Prozeß (Prozeß 1), indem er eine Kopie von sich selbst anfertigt. Prozeß 1 wird auch "init" genannt. Das System gibt das Äquivalent des Systemaufrufs "brk" aus, um die Größe von Prozeß 1 zu erweitern. Danach wird ein Programm, das die Anweisungen zur Durchführung eines Systemaufrufs exec enthält, in das Textsegment des neu erzeugten Prozesses 1 geladen.
Der Prozeß 0 ist kein Abbild eines abgeschlossenen Prozesses. Der Kernel verwendet diesen Prozeß zur Zeitplanung und Steuerung der Vorgänge anderer Prozesse. Prozeß 1 ist das Abbild des ersten abgeschlossenen Prozesses und der Vorfahre aller folgender Prozesse. Keiner der beiden Prozesse wurde ausgeführt. Der Scheduler teilt den ersten Prozeß zu, der zur Ausführung bereit steht. Es gibt nur einen Prozeß, der zur Ausführung bereit steht; es wird also Prozeß 1 ausgeführt. Prozeß 1 führt sofort den Systemaufruf "exec" durch, um sich selbst mit Code aus der Datei "/etc/init" zu überlagern.
Wie bereits erwähnt, sind alle anderen Prozesse Nachfahren dieses Init-Prozesses. Normalerweise führt der Init-Prozeß die Shell-Prozedur /etc/rc aus. Die Prozedur "rc shell" ist die für die Überprüfung der Vollständigkeit, notwendige Bereinigungen, den Aufbau des normalen Dateisystems und die Freigabe der Standardanschlüsse verantwortlich. Wenn /etc/rc mit Erfolg ausgeführt wird, erzeugt der Init-Prozeß für jeden in der Datei /etc/ports angegebenen freigegebenen Anschluß mittels des Systemaufrufs fork ein "getty". Der Init-Prozeß ruft über den Systemaufruf "exec" getty auf, um die richtige Geschwindigkeit und die richtigen Betriebsarten der Datenstation zu ermitteln. Das Programm getty ruft über den Systemaufruf "exec" login auf, um das Kennwort zu prüfen und setzt die Benutzerkennung (UID, user id) und die Gruppenkennung (GID, group id), das aktuelle Verzeichnis und so weiter. "Login" führt shell oder das Programm aus, das in der Datei /etc/passwd als das Programm aufgeführt ist, das als erstes nach login ausgeführt werden soll. Shell läuft im gleichen Prozeß, den init erzeugt hat. Shell führt den Systemaufruf "fork" durch, der für jeden Befehl neue Prozesse erzeugt. Während der Ausführung des Systems wartet der Init- Prozeß im Hintergrund auf die Beendigung irgendeines seiner Kinder. Wenn sich ein Benutzer abmeldet, erzeugt init über einen Systemaufruf fork ein neues Anmeldeprogramm.
Eltern- und Kindprozesse: Ein Prozeß kann aus verschiedenen Gründen eine Kopie von sich selbst erstellen. Wenn dies geschieht, wird der ursprüngliche Prozeß "Elternprozeß" und der neu erzeugte Prozeß "Kindprozeß" genannt. Der Hauptunterschied zwischen dem ursprünglichen Prozeß, den Eltern, und dem erzeugten Prozeß, dem Kind, besteht darin, daß sie unterschiedliche Prozeßkennummern besitzen, daß ihre Elternprozesse unterschiedliche Kennummern aufweisen und daß sie unterschiedliche Daten zur Abrechnung der Maschinenzeit besitzen.
Der Systemaufruf "fork" bewirkt, daß die Gesamtzahl der Systemprozesse zunimmt. Der Systemaufruf "fork" dient dazu, daß ein Prozeß eine Kopie von sich selbst erstellt. Der Systemaufruf "fork" erzeugt einen neuen Prozeß, das Kind. Außer den zuvor genannten Unterschieden erhalten sie jeweils vom Systemaufruf "fork" einen unterschiedlichen Wert (Das Kind erhält den Wert 0, und der Elternprozeß erhält die Kennung des Kindprozesses). Die beiden Prozesse benutzen gemeinsam offene Dateien, und jeder der beiden Prozesse kann über den zugeteilten Wert feststellen, ob er der Eltern- oder der Kindprozeß ist. Der Elternprozeß kann darauf warten (muß es aber nicht), daß irgendeines seiner Kinder beendet wird.
Der Systemaufruf "exec" bewirkt, daß der Prozeß die Informationen, die er enthält, mit neuen Informationen überlagert. Während des Systemaufrufs "exec" vertauscht der Prozeß die aktuellen Text- und Datensegmente mit neuen Text- und Datensegmenten. Die Gesamtzahl der Systemprozesse ändert sich nicht; nur der Prozeß, der "exec" aufgerufen hat, ist davon betroffen. Nach dem Systemaufruf "exec" ist die Prozeßkennummer unverändert, und offene Dateien bleiben offen (außer Dateien mit dem Attribut Schließen bei "exec").
Prozesse, die den Systemaufruf "exit" aufrufen, werden dadurch beendet. Alle Dateien, auf die dieser Prozeß zugegriffen hat, werden geschlossen, und der wartende Elternprozeß wird darüber informiert. Ein Geisterprozeß ist ein beendeter Prozeß, dessen Eintrag noch in der Prozeßtabelle verblieben ist. Der Elternprozeß ist dafür verantwortlich, den Eintrag aus der Prozeßtabelle zu löschen. Für den Fall, daß der Elternprozeß eines Kindes beendet worden ist, wird init zu dessen Elternprozeß und löscht den Eintrag. Wenn eine Abrechnung durchgeführt werden soll, schreibt "exit" einen Abrechnungsdatensatz.
Der Systemaufruf "wait" setzt den aufrufenden Prozeß solange aus, bis der Kindprozeß endet, das Kind im Ablaufverfolgungsmodus anhält (der Ablauf des Kinds wird von seinen Eltern verfolgt) oder der aufrufende Prozeß ein Signal erhält. Der Systemaufruf "wait" gibt den Beendigungsstatus an den Elternprozeß weiter; das höherwertige Byte stammt von "exit", das niederwertige Byte enthält den Systemstatus. Dieser Systemaufruf entfernt auch Geisterprozesse aus der Prozeßtabelle.
Das folgende, in Fig. 6 gezeigte Szenarium erläutert die Beziehung zwischen Eltern- und Kindprozeß und die Systemaufrufe zu deren Synchronisation. Es ist wichtig, zu beachten, daß der Elternprozeß vor dem Kindprozeß enden kann. In diesem Fall übernimmt der Init-Prozeß die Rolle des Elternprozesses.
Ein Elternprozeß führt einen Systemaufruf "fork" aus, wobei ein neuer Prozeß entsteht. Der neue Prozeß führt einen Systemaufruf "exec" aus, der einen Kindprozeß mit einer neuen Identität erzeugt. Dies ist ähnlich wie die Abfolge, die "shell" verwendet, wenn es ein Programm ausführt. Der Systemaufruf "wait" bewirkt, daß ein Elternprozeß darauf wartet, daß das Kind mit der Arbeit aufhört. Wenn der Shell-Prozeß im Dialogbetrieb abläuft, führt er einen Systembefehl "fork" aus, der Kindprozeß (shell läuft im neuen Prozeß) ruft über den Systemaufruf exec das gewünschte Programm auf, und der Elternprozeß (shell) führt einen Systemaufruf wait aus, um auf das Ende der Ausführung des Kinds zu warten. Wenn das Kind einen Systemaufruf "exit" ausführt, sorgt der Elternprozeß dafür, daß der Eintrag für das Kind in der Prozeßtabelle entfernt wird und fordert einen weiteren Befehl an. Wenn der Shell-Prozeß im Hintergrund läuft, gibt er einfach die Prozeßkennung des Kinds aus und wartet nicht auf das Ende des Kindprozesses. Zur Beziehung zwischen dem Eltern- und dem Kindprozeß, wenn diese wie beschrieben interaktiv ablaufen, siehe Fig. 6.
Status eines Prozesses: Ein Prozeß kann sich, wie Fig. 7 zeigt, in vielen Status befinden. Ein Prozeß kann zur Ausführung bereitstehen, gerade laufen, ruhen (auf ein Ereignis warten), angehalten oder beendet sein. Der Scheduler bestimmt, in welcher Reihenfolge die konkurrierenden Prozesse ausgeführt werden. Das Diagramm in Fig. 7 zeigt die Prozeßstatus und die Ereignisse, die die Status verändern.
Zu einem bestimmten Zeitpunkt ist nur ein einziger Benutzerprozeß aktiv bzw. wird gerade ausgeführt. Die Ausführung aller anderen Benutzerprozesse ist aufgeschoben. Beispielsweise wartet ein Prozeß, der darauf wartet, daß irgendeines seines Kinder beendet wird, auf ein Ereignis, das die Adresse seines eigenen Prozeßtabelleneintrags darstellt. Wenn ein Prozeß endet, signalisiert er dieses Ereignis, das durch den Prozeßtabelleneintrag seines Elternprozesses dargestellt wird. Tritt das Ereignis ein, dann wird der Prozeß aufgeweckt. Wenn ein Prozeß aufgeweckt worden ist, ist er bereit zur Ausführung, was bedeutet, daß er zur Ausführung ausgewählt werden kann. Sofern Prozesse nicht ruhen, laufen sie normalerweise vollständig ab. Der Grund für ihr Ruhen ist z. B. das Warten darauf, daß eine Eingabe oder Ausgabe abgeschlossen wird, das Warten auf Zeitscheiben, das Warten darauf, daß ein Ereignis eintritt oder das Warten auf Signale von anderen Prozessen. Bei jeder Zeitgeberunterbrechung überprüft die Zeitgeberunterbrechungsroutine die Prozeßwarteschlangen und bewirkt möglicherweise eine Prozeßumschaltung. Wenn ein Prozeß ruht, kann er aus dem Speicher ausgelagert werden. Die Prozeßumschaltroutine startet einen ausgelagerten Prozeß nicht erneut. Bevor sie den Prozeß erneut startet, prüft sie, ob der Kernel und die Benutzerdaten eines Prozesses adressiert werden können.
Ein Prozeß, der die Kontrolle über den Prozessors abgibt, wartet gewöhnlich darauf, daß irgendwelche E/A ausgeführt werden. In diesem Fall sendet der Prozeß den Aufruf "Ruhen", der "chan" angibt, was normalerweise die Adresse der Datenstruktur des Kernels ist, und er gibt auch eine Aufwachpriorität an. Er ruht normalerweise so lange weiter, bis ein Aufruf "Aufwachen" mit der gleichen Angabe für chan erfolgt. Ist die "Aufwach"-Priorität niedrig genug, damit das Signal verarbeitet wird, wird der Prozeß aufgeweckt und im gleichen Modus wie vor dem Ruhen erneut gestartet. Manchmal kann es vorkommen, daß viele Prozesse auf das Auftreten des gleichen Ereignisses warten, z. B. auf die Speicherzuweisung. Da dies möglich ist, wenn der Prozeß vom Ruhen zurückkehrt, muß er zuerst prüfen, ob das Ereignis oder das Betriebsmittel nicht von einem anderen Prozeß belegt worden ist, der auf dem gleichen chan wartet. Steht das Betriebsmittel nicht zur Verfügung, sendet der Prozeß einen weiteren Aufruf "Ruhen".
Signale: Signale sorgen für Kommunikation mit einem aktiven Prozeß und erzwingen dabei eine Reihe von Ereignissen, wobei die Umgebung des aktuellen Prozesses zwischengespeichert und eine neue erstellt wird. Ein Prozeß kann eine Signalbehandlungsroutine angeben, die auf das Signal reagiert. Die Signale besitzen alle die gleiche Priorität, und kritische Funktionen können sich vor Signalüberlagerung schützen.
Ein Signal ist ein Ereignis, das die normale Ausführung eines Prozesses unterbricht. Der Signalsatz wird vom AIX-System festgelegt, z. B. SIGINT für eine Unterbrechung. Alle Signale haben die gleiche Priorität. Ein Prozeß kann eine Signalbehandlungsroutine angeben, die aufgerufen werden soll, wenn das Signal auftritt. Er kann aber auch angeben, daß ein Signal gesperrt bzw. ignoriert werden soll oder daß das System eine Standardhandlung ausführt, wenn ein Signal auftritt.
Eine globale Signalmaske legt diejenigen Signale fest, bei denen die Übergabe an einen Prozeß zur Zeit gesperrt ist. Die Signalmaske eines Prozesses wird aus der Signalmaske seines Elternprozesses initialisiert. Sie kann durch die Systemaufrufe "sigblock" bzw. "sigsetmask" geändert werden. Wenn gerade eine Signalbehandlungsroutine ausgeführt wird, wird das Signal, das ihren Aufruf bewirkt hat, gesperrt; andere Signale können jedoch auftreten. Wenn die Signalbehandlungsroutine abgeschlossen ist, ist das Signal wieder freigegeben.
Normalerweise werden Signalbehandlungsroutinen auf dem aktuellen Stack des Prozesses ausgeführt. Dies kann durch ein Benutzersignals so geändert werden, daß die Signalbehandlungsroutinen auf einem Sonderstack für Signale ausgeführt werden.
Wenn ein Signal an einen Prozeß geschickt wird, wird es einer Reihe von Signalen zugefügt, die für den Prozeß anstehen. Wenn das Signal zur Zeit nicht gesperrt ist, wird es an den Prozeß übergeben. Wenn ein Signal übergeben wird, treten folgende Vorgänge ein:
1. Der aktuelle Status des Prozeßausführungskontexts wird zwischengespeichert.
2. Eine neue Signalmaske wird berechnet, die für die Dauer der Signalbehandlungsroutine des Prozesses oder bis zu einem Systemaufruf "sigblock" bzw. "sigsetblock" wirksam bleibt. Die neue Maske wird hergestellt, indem die aktuelle Signalmaske mit logisch ODER verknüpft wird, das Signal wird übergeben, und die Signalmaske wird mit der aufzurufenden Behandlungsroutine verknüpft.
3. Soll die Signalbehandlungsroutine auf dem Signalstack ausgeführt werden, dann wird der Signalstack zum aktuellen Stack gemacht.
4. Die Signalbehandlungsroutine wird aufgerufen. Die Parameter, die der Behandlungsroutine übergeben werden, werden in der folgenden Beschreibung definiert.
Das Unterprogramm Signalbehandlungsroutine kann wie folgt deklariert werden:
Name der Behandlungsroutine (sig, code, scp) "int" sig, code;
"struc sigcontext *" scp;
Der Parameter sig ist die Nummer des Signals. Der Parameter code dient nur der Kompatibilität zu anderen UNIX-kompatiblen Systemen; er ist stets Null. Der Parameter scp zeigt auf die Struktur "sigcontext", die später verwendet wird, um den vorherigen Ausführungskontext des Programms wiederherzustellen.
5. Wenn die Signalbehandlungsroutine normal beendet wird, wird der vorherige Kontext wiederhergestellt, und der Prozeß nimmt seine Tätigkeit wieder an der Stelle auf, an der er unterbrochen wurde. Die Behandlungsroutine kann veranlassen, daß der Prozeß durch Aufruf des Unterprogramms "longjmp" in einem anderen Kontext einsteigt.
Nach dem Systemaufruf "fork", erbt der Kindprozeß alle Signale, die Signalmaske und den Signalstack von seinem Elternprozeß.
Die Systemaufrufe "exec" setzen alle aufgenommenen Signale auf die Standardaktion zurück. Signale, welche die Standardaktion bewirken, tun dies auch weiterhin. Ignorierte Signale werden weiter ignoriert, die Signalmaske bleibt gleich, und der Status des Signalstacks wird zurückgesetzt.
Wird das Unterprogramm "longjmp" aufgerufen, dann verläßt der Prozeß den Signalstack, wenn er sich zur Zeit auf diesem befindet, und setzt die Signalmaske wieder in den Status ein, bei dem der entsprechende Aufruf "setjmp" erfolgte. Das Betriebssystem besitzt fünf Signalklassen:
1. Hardwaresignale treten aufgrund von Bedingungen wie z. B. arithmetischen Ausnahmen, der Ausführung unzulässiger Befehle oder Speicherschutzverletzungen auf.
2. Softwaresignale sind normalerweise durch den Benutzer initiierte Unterbrechungen. Die Signale Beenden, Verlassen und Löschen sind Signalarten, die verschiedene Ebenen von benutzer- oder programminitiierten Signalen an einen Prozeß darstellen. Zusätzlich kann das Ablaufen des Zeitgebers mit softwaregesteuerten "Alarm" -Signalen signalisiert werden.
3. Ein Prozeß kann über ein Ereignis unterrichtet werden, das aufgrund eines Deskriptors oder einer gerade fertig werdenden, nicht-sperrenden Aktion eintritt. Ein Prozeß kann auch ein Signal für einen schweren Störfall anfordern.
4. Der Prozeß kann angehalten, neu gestartet oder über Statusänderungen in einem Kindprozeß benachrichtigt werden.
5. Prozesse können Warnungen bei Schwellenwerten erhalten, wenn das Zeitlimit der Verarbeitungseinheit oder ein Dateigrößenlimit erreicht ist.
Auch der Kernel enthält Erweiterungen und Veränderungen zur Verbesserung des Signalsystems bei unverlangten Unterbrechungen für die Kommunikation vom Kernel zum Prozeß.

Ausführungsbeispiel für die Erfindung im Betriebssystem AIX

Als Mehrplatzbetriebssystem braucht UNIX (TM) (UNIX ist Warenzeichen der AT&T Laboratories) einen Mechanismus, der verhindert, daß unberechtigte Programme Daten aus einer Benutzerdatenstation lesen. Der Sicherheitswegmechanismus stellt sicher, daß die Daten, die der Benutzer über die Tastatur einer Datenstation eingegeben hat, vor eventuellem Eindringen durch unberechtigte Programme geschützt sind. Der Sicherheitspfadmechanismus gestattet einem Benutzer die Einrichtung eines fälschungs- und einbruchssicheren Kommunikationspfads zwischen der Datenstation des Benutzers und der "gesicherten" Betriebssystem-Software. Der Benutzer kann durch einfaches Drücken einer Sicherheitsanforderungstaste (SAK) genannten Taste auf der Tastatur der Datenstation vor der Anmeldung im System einen Sicherheitsweg einrichten, um sicherzugehen, daß er mit dem echten Anmeldeprogramm (Programm login) und nicht mit einem Programm kommuniziert, das sich als Anmeldeprogramm ausgibt und den Auftrag hat, das Kennwort des Benutzers zu stehlen. Nachdem sich der Benutzer zur Eingabe seiner geheimen Daten, z. B. einem Kennwort, angemeldet hat, kann er sicher sein, daß sie nicht durch das Programm eines Eindringlings gestohlen werden können. Wenn sich der Benutzer wieder abmeldet, kann er sicher sein, daß ihn der Sicherheitsweg auch wirklich vom System abgemeldet hat.
Der Aufbau des Sicherheitswegmechanismus gilt für beliebige UNIX- oder UNIX-artige (XENIX, AIX o.a.) Betriebssysteme.
Zur Implementierung des Sicherheitswegmechanismus werden in XENIX und AIX folgende Änderungen durchgeführt:
1. Es wird eine neue Tastenfolge aus einer oder mehreren ASCII- Tasten definiert, die als Sicherheitsanforderungstaste (SAK) erkannt wird. Der Systementwickler kann den SAK seiner Wahl wählen. Es ist günstig, für den SAK eine seltene, aus mehr als einem ASCII-Zeichen bestehende ASCII-Folge zu wählen.
2. Eine neuer UNIX-Signaltyp, genannt SIGSAK, wird hinzugefügt. Dieses Signal kann nur von privilegierten Programmen verarbeitet (ignoriert oder aufgenommen) werden. Wird das SIGSAK- Signal an ein unprivilegiertes Benutzerprogramm geschickt, beendet es das Programm dieses Benutzers.
3. Ein Programm mit der effektiven Kennung (UID) 0 (root) in einem UNIX-System ist ein privilegiertes Programm (auch Programm mit Superuser-Privileg genannt). Einige UNIX- Systeme, die das Superuser-Privileg nicht unterstützen, bieten andere Arten von Mechanismen, um Programmen Privilegien zuzuordnen, z. B. bietet Secure Xenix zum Zuweisen von Privilegien an Programme einen vom Superuser-Privileg verschiedenen Generalized Privileged Mechanism (GPM).
4. Der Leitungsdisziplintreiber wird so verändert, daß er den SAK vom Hardwareunterbrechungsanschluß des Benutzers bemerkt und das SIGSAK-Signal an alle Prozesse in der Prozeßgruppe der Steuerdatenstation sendet.
5. Das UNIX-Programm init wird abgeändert, um (i) das Ende seines Kindprozesses durch das SIGSAK-Signal festzustellen, (ii) die Datenstation des Benutzers für die Dauer des Sicherheitswegs vor unberechtigtem Zugriff zu schützen, (iii) nach der Einrichtung eines Sicherheitswegs einen gesicherten Prozeß für die Datenstation des Benutzers auszuführen, (iv) den Eintrag für die Datenstation des Benutzers in der Datei /etc/utmp zu aktualisieren, um damit anzuzeigen, daß für die Datenstation des Benutzers ein Sicherheitsweg besteht, und (v) die Beendigung eines Sicherheitswegs festzustellen und die Anmeldeumgebung für einen Benutzer herzustellen.
6. Die Struktur der Datei /etc/utmp wird so abgeändert, daß sie die Parameter termio (Merkmale der Datenstation) der Benutzerdatenstation enthält. Dem Feld ut_type der utmp-Struktur wird zudem eine neue Marke, genannt TSH_PROCESS, hinzugefügt. Diese Marke zeigt an, daß zwischen der Benutzerdatenstation und der Software des Betriebssystems ein Sicherheitsweg eingerichtet worden ist und daß der gerade laufende Benutzerprozeß für die Datenstation die gesicherte Shell ist. Die gesicherte Shell ist ein begrenzter Befehlsinterpreter, der es Benutzern ermöglicht, eine Reihe sicherheitsrelevanter Befehle wie z. B. den Befehl passwd zum Ändern des Kennworts auszuführen.
7. Die UNIX-Programme login und getty werden so abgeändert, daß die Parameter termio für die Datenstation in der Datei /etc/utmp abgelegt werden.

Ausführung

Ein Benutzer kann durch Drücken des SAK auf der Tastatur seiner asynchronen Datenstation jederzeit einen Sicherheitsweg einrichten. Der SAK arbeitet sowohl im unformatierten als auch im aufbereiteten E/A-Modus (Eingabe/Ausgabe-Modus) der Datenstation.
Der Benutzer kann den SAK zum Zeitpunkt der Systemanmeldung drücken, um sicherzugehen, daß er mit dem echten Anmeldeprogramm (Programm login) und nicht mit einem Programm kommuniziert, welches das Programm login "hereinlegt". Der Benutzer kann den SAK aber auch nach der Systemanmeldung drücken, um sichere Vorgänge wie das Ändern eines Kennworts durchzuführen. Der Benutzer kann den SAK auch nach der Abmeldung vom System drücken, um sicherzustellen, daß er sich tatsächlich vom System abgemeldet hat. Im folgenden wird der ihn Ebenen gegliederte Aufbau des Sicherheitswegmechanismus beschrieben.

Feststellen, ob der SAK gedrückt worden ist

Wenn der Benutzer den SAK drückt, empfängt der Datenstationstreiber die Tasten (ASCII-Zeichen) und übergibt sie an den Leitungsdisziplintreiber. Nach dem Empfang der Tasten, führt der Leitungsdisziplintreiber folgende Vorgänge durch:
1. Falls für den SAK mehr als eine Taste ausgewählt worden ist, puffert der Leitungsdisziplintreiber die zu Beginn gedrückten Tasten so lange, bis alle Tasten des SAK gedrückt worden sind oder die Tastenfolge abbricht oder ein gegebenes Zeitlimit, das SAK-Zeitlimit, überschritten wird. Falls die eingegebene Tastenfolge nicht der SAK ist, übergibt der Leitungsdisziplintreiber wie gewöhnlich die Taste(n) an die Anwendung.
2. Wenn der Leitungsdisziplintreiber den SAK feststellt, schickt er das SIGSAK-Signal an alle Prozesse in der Prozeßgruppe der Steuerdatenstation. Sämtliche Prozesse (einschließlich der Prozeß auf der obersten Benutzerebene, normalerweise eine Shell), die das SIGSAK-Signal erhalten, es aber nicht ignorieren oder abfangen können, werden beendet.

Feststellung des SIGSAK-Signals

Wenn ein Prozeß, der ein Kind von init ist, aufgrund des SIGSAK- Signals vom Leitungsdisziplintreiber endet, erhält init das Signal SIGCLD (Tod eines Kinds) zusammen mit dem Ausführungsstatus des Kindprozesses. Durch Abfragen des Ausführungsstatus seines Kindprozesses stellt init dann fest, daß das SIGSAK- Signal eingetreten ist. Der Prozeß init besitzt die Prozeßkennung eins. Ein Kindprozeß von init (d. h. ein Prozeß mit der Elternprozeßkennung eins) wird Prozeß der höchsten Stufe genannt.

Einrichtung eines Sicherheitswegs

Nach der Feststellung des SIGSAK-Signals anhand des Ausführungsstatus eines Kindprozesses richtet init einen Sicherheitsweg zwischen der Benutzerdatenstation und der Software des "gesicherten" Betriebssystems ein und führt in Anhängigkeit des Status des Prozesses, der vor dem Drücken des SAK lief, ein gesichertes Programm in der Datenstation aus. Im folgenden werden die Vorgänge erläutert, die init durchführt, um einen Sicherheitsweg einzurichten und einen gesicherten Prozeß auszuführen.

Vor der Anmeldung

Falls ein Benutzer vor der Anmeldung den SAK drückt, ist der Prozeß der höchsten Stufe einer freigegebenen Datenstation entweder getty oder login, das sich ebenfalls in der Prozeßgruppe dieser Datenstation befindet. Das Feld ut_type für jeden Datensatz in der Datei /etc/utmp zeigt den Typ des auf dieser Datenstation gerade laufenden Prozesses an. Das Feld ut_type für getty und login ist INIT_PROCESS bzw. LOGIN_PROCESS in der Datei /etc/utmp. Wenn der Benutzer den SAK drückt, schickt der Leitungsdisziplintreiber das SIGSAK-Signal an alle Prozesse in der Prozeßgruppe der Steuerdatenstation. Dadurch werden alle Prozesse einschließlich des Prozesses getty bzw. login, die gerade in der Datenstation laufen, beendet.
Init fragt den Ausführungsstatus seines Kindprozesses ab und stellt dadurch fest, daß der Kindprozeß aufgrund des Signals SIGSAK beendet worden ist. Init ermittelt dann den Typ dieses laufenden Prozesses durch Auslesen des Felds ut_type für den Eintrag für die Datenstation in der Datei /etc/utmp. In diesem Fall ist ut_type entweder INIT_PROCESS, falls getty gerade lief, oder LOGIN_PROCESS, falls login gerade lief. Init erzeugt dann (mittels "fork") einen neuen Kindprozeß. Im Kindprozeß ändert es den Zugriffsmodus der Datenstation in -rw------- (nur der Besitzer darf schreiben und lesen), ändert die Besitzerkennung und die Gruppenkennung in root (UID=0; GID=0), eröffnet die Datenstation und nimmt den Schreib/Lese-Zugriff für alle Prozesse dieser Datenstation mittels des Systemaufrufs vhangup wieder zurück. Dadurch werden eventuelle frühere Programmzugriffe aus der Datenstation entfernt. Dadurch wird ein Sicherheitsweg für die Datenstation des Benutzers eingerichtet und die Datenstation vor dem Lesen und Schreiben durch unberechtigte Programme geschützt.
Aufgrund des Zugriffsmodus und der Besitzverhältnisse kann nun nur ein Superuser (root) die Datenstation eröffnen. Init als Superuser-Programm eröffnet dann die Datenstation von neuem und führt (mittels exec) den Prozeß getty (ein gesicherter Prozeß) aus, der den Benutzer nach einer neuen Anmeldung fragt.

Nach der Anmeldung

Falls ein Benutzer den SAK nach der Anmeldung drückt, ist der Prozeß der höchsten Stufe ein Benutzerprozeß, der auch in der Prozeßgruppe der Datenstation ist. Das Feld ut_type eines Benutzerprozesses in der Datei /etc/utmp ist entweder USER_PROCESS oder TSH_PROCESS. Wenn ein Benutzer den SAK drückt, schickt der Leitungsdisziplintreiber das SIGSAK-Signal an alle Prozesse in der Prozeßgruppe der Steuerdatenstation. Dadurch enden alle Prozesse, die gerade in der Datenstation laufen, einschließlich des Benutzerprozesses der höchsten Stufe.
Init stellt durch Abfragen des Ausführungsstatus seines Kindprozesses (Benutzerprozeß) fest, daß der Kindprozeß aufgrund des SIGSAK-Signals endet. Init ermittelt dann durch Auslesen des Feldes ut_type für den Eintrag der Datenstation in der Datei /etc/utmp den Typ dieses gerade laufenden Prozesses. In diesem Fall ist ut_type entweder USER_PROCESS, falls der Sicherheitsweg nicht eingerichtet worden ist, oder TSH_PROCESS, falls der Sicherheitsweg bereits eingerichtet worden ist. Init verzweigt dann mittels "fork" zu einem neuen Kindprozeß. Im Kindprozeß ändert es den Zugriffsmodus der Datenstation zu -rw------- (nur der Besitzer darf lesen und schreiben), ändert die Besitzerkennung und die Gruppenkennung in root (UID=0; GID=0), eröffnet die Datenstation und nimmt den Schreib/Lese-Zugriff für alle Prozesse dieser Datenstation mittels des Systemaufrufs vhangup wieder zurück. Dadurch werden eventuelle frühere Programmzugriffe aus der Datenstation entfernt. Dadurch wird ein Sicherheitsweg für die Datenstation des Benutzers eingerichtet und die Datenstation vor dem Lesen und Schreiben durch unberechtigte Programme geschützt.
Aufgrund des Zugriffsmodus und der Besitzverhältnisse kann nun nur ein privilegiertes Programm die Datenstation eröffnen. Init als privilegiertes Programm eröffnet dann die Datenstation von neuem und ändert das Feld ut_type für diesen Eintrag der Datenstation in der Datei /etc/utmp in TSH_PROCESS, setzt die Parameter termio des Terminals auf die in der Datei /etc/utmp definierten termio-Werte für das Terminal und führt dann die gesicherte Shell aus.
Falls der Benutzer den SAK während der gesicherten Shell nochmal drückt, werden die gleichen Vorgänge durchgeführt, als ob der Benutzer angemeldet ist und keinen Sicherheitsweg eingerichtet hat. Dadurch wird die gesicherte Shell beendet, ein neuer Sicherheitsweg eingerichtet und die gesicherte Shell für diese Datenstation erneut ausgeführt.
Wenn der Benutzer die gesicherte Shell verläßt, stellt init durch Auslesen des entsprechenden Eintrags in /etc/utmp fest, daß es sich um eine gesicherte Shell gehandelt hat. Es ändert dann das Feld ut_type für den Eintrag der Datenstation in der Datei /etc/utmp in USER_PROCESS, erzeugt die Anmeldeumgebung für den Benutzer einschließlich der termio-Parameter und führt das Anmeldeprogramm des Benutzers (normalerweise eine Anmelde-Shell) aus.

Nach dem Abmelden

Falls der Benutzer den SAK nach dem Abmelden drückt, hat dies die gleiche Wirkung wie oben beschrieben vor der Anmeldung.
Nun wird auf Fig. 8 Bezug genommen, die das Zustandsdiagramm bei gedrücktem SAK zeigt. Der Zustand S1 liegt vor der Anmeldung, wenn das System mit dem echten Anmeldeprogramm kommuniziert, vor. Im Zustand S2 war die Anmeldung erfolgreich, es ist jedoch noch kein Sicherheitsweg eingerichtet. Im Zustand S3 war die Anmeldung erfolgreich, und es ist ein Sicherheitsweg eingerichtet, d. h. es besteht eine gesicherte Shell TSH. Gemäß Fig. 8 gelangt der Benutzer in den Zustand S1, wenn er seine Datenstation anschaltet. Falls er zu diesem Zeitpunkt die Sicherheitsanforderungstaste SAK drücken sollte oder falls alternativ die Anmeldung fehlschlagen sollte, bliebe er weiter im Zustand S1. Falls sich der Benutzer jedoch mit Erfolg anmeldet, gelangt er vom Zustand S1 in den Zustand S2. Im Zustand S2 kann der Benutzer die Anmelde-Shell durch Drücken einer bestimmten Tastenkombination verlassen und in den Zustand S1 zurückkehren. Als weitere Möglichkeit kann der Benutzer im Zustand S2 wie gewöhnlich nicht gesichert arbeiten und im Zustand S2 bleiben, wo er innerhalb der Shell SH arbeitet. Falls sich der Benutzer im Zustand S2 mittels eines Sicherheitswegs in Transaktionen zwischen seiner Datenstation und der Computersicherheitsbasis einschalten möchte, kann er als weitere Möglichkeit die Sicherheitsanforderungstaste (SAK) drücken. Dadurch gelangt der Benutzer in den Zustand S3. Der Benutzer kann den Zustand S3 durch Verlassen der gesicherten Shell TSH verlassen und in die nicht gesicherte Shell SH im Zustand S2 zurückkehren, indem er die bestimmte Tastenkombination drückt. Als weitere Möglichkeit kann der Benutzer im Zustand S3 die Sicherheitsanforderungstaste SAK drücken oder einen Befehl der gesicherten Shell ausführen; beides bewirkt, daß er in der gesicherten Shell des Zustands S3 bleibt. Nachdem der Benutzer die in der gesicherten Shell im Zustand S3 durchzuführenden Aufgaben abgeschlossen hat, verläßt er die gesicherte Shell und kehrt in den Zustand S2 zurück.
Die Folge der Fig. 9-15 beschreibt, wie ein Sicherheitsweg zwischen der Datenstation des Benutzers und der Computersicherheitsbasis eingerichtet wird, wie die gesicherte Shell eingesetzt und beendet wird, so daß der Benutzer sie verläßt und von seinem Sicherheitsweg zu gewöhnlichen, nicht gesicherten Vorgängen zurückkehrt. Fig. 9 zeigt den Init-Prozeß. Fig. 10 schließt sich an Fig. ,9 an und zeigt, wie der Init-Prozeß zur Erzeugung eines Kindprozesses "fork" aufruft und der Kindprozeß dann mittels "exec" den Prozeß "getty" aufruft, der die anfängliche Anmeldeaufforderung ausgibt und die Eigenschaften der Datenstation ermittelt. Fig. 11 schließt sich an Fig. 10 an und zeigt, daß getty den Anmeldeprozeß ausführt, wenn ein Benutzer seinen Benutzernamen an getty mitteilt. Fig. 12 schließt sich an Fig. 11 an und zeigt, daß der Anmeldeprozeß nach einer erfolgreichen Anmeldung die für diesen Benutzer angegebene Anmelde-Shell, z. B. SH, ausführt. Fig. 13 schließt sich an Fig. 12 an und zeigt, daß der Leitungsdisziplintreiber ein SIGSAK-Signal an alle Prozesse in der Prozeßgruppe der Steuerdatenstation sendet, nachdem der Benutzer die Sicherheitsanforderungstaste (SAK) gedrückt hat. Daraufhin stirbt die Anmelde-Shell SH, und der Init-Prozeß verzweigt zu einem neuen Kindprozeß, der wiederum einen gesicherten Shell-Prozeß TSH ausführt. Fig. 14 schließt sich an Fig. 13 an und zeigt, daß, falls das Programm password innerhalb der gesicherten Shell TSH ausgeführt wird, TSH dann zu einem Kindprozeß verzweigt, der seinerseits password ausführt. Nach Beendigung des Prozesses password läuft immer noch die gesicherte Shell TSH. Fig. 15 schließt sich an Fig. 14 an und zeigt, daß die gesicherte Shell TSH die Funktion exit ausführt und dadurch den Sicherheitsweg beendet, der zwischen der Benutzerdatenstation und der Computersicherheitsbasis eingerichtet worden war.
Die Fig. 16 und 17 zeigen alternative Umstände für die Anwendung der Erfindung, bei der die Shell SH im Mehrprozessor- oder Mehrprogrammbetrieb eine Vielzahl von Anwendungsprozessen ausführt. Fig. 16 zeigt einen alternativen Zustand zu dem in Fig. 12 gezeigten, bei dem unter der Shell SH eine Vielzahl von Prozessen in einem Mehrprogramm- oder Mehrprozessorbetrieb ausgeführt werden können. Fig. 17 schließt sich an Fig. 16 an und zeigt alternative Umstände zu den in Fig. 13 gezeigten, bei denen, wenn die Sicherheitsanforderungstaste gedrückt ist, die Shell SH mit ihrer Vielzahl von Betriebsprozessen beendet wird und der Init-Prozeß die gesicherte Shell TSH erzeugt und dadurch, wie bereits beschrieben, einen Sicherheitsweg einrichtet.
Die Fig. 18, 19 und 20 zeigen schematisch, wie eine Shell SH, die im Mehrprozessor- oder Mehrprogrammbetrieb arbeitet und ein als Trojanisches Pferd arbeitendes Programm enthält, vom Benutzer in einen Sicherheitsweg umgewandelt wird, so daß der Benutzer eine gesicherte Kommunikation zwischen seiner Datenstation und der Computersicherheitsbasis ausführen kann. Fig. 18 ist ein schematisches Diagramm eines Verarbeitungszustands des Systems, bei dem die Shell SH zwei Prozesse ausführt, ein Kalkulationsprogramm und ein Datenbankprogramm (DB-Programm), mit dem ein als Trojanisches Pferd arbeitendes verknüpft ist. Fig. 19 zeigt, wie der Benutzer durch Drücken seiner Sicherheitsanforderungstaste (SAK) einen Sicherheitsweg zwischen seiner Datenstation und der Computersicherheitsbasis einrichten kann, wodurch die Shell SH und ihre zugehörigen Prozesse, nämlich das Kalkulationsprogramm, das Datenbankverwaltungsprogramm und, was am wichtigsten ist, das als Trojanisches Pferd arbeitende Programm, zerstört werden. Fig. 19 zeigt, wie der Init-Prozeß den gesicherten Shell-Prozeß TSH erstellt. Fig. 20 zeigt, daß, nachdem der gesicherte Shell-Prozeß TSH die vom Benutzer gewünschte Aufgabe über dessen Sicherheitsweg erledigt hat, die gesicherte Shell TSH auf natürliche Weise endet oder verlassen wird, was bewirkt, daß init wieder die Shell SH erzeugt.
Um den Sicherheitsweg auf verläßliche Weise einzurichten, muß die Computersystemeinheit physisch sicher sein. Die Systemeinheit muß genügend physische Sicherheit haben, damit unberechtigte Personen nicht das Gehäuse öffnen können und Zugriff auf die darin befindliche Festplatte erhalten. Die Systemeinheit muß zudem so eingerichtet sein, daß der Benutzer nicht nach seiner Wahl irgendein Betriebssystem laden kann. Das einzige Betriebssystem, für das eine Erlaubnis zum Laden bestehen sollte, ist das gesicherte UNIX-artige Betriebssystem gemäß der Erfindung. Eine Möglichkeit, auszuschließen, daß nicht gesicherte UNIX- artige Betriebssysteme geladen werden, besteht darin, zu verhindern, daß der Benutzer Betriebssysteme von in die Systemeinheit eingeschobenen Disketten bootet. Dies läßt sich ganz einfach bewerkstelligen, indem die Stecker in der Systemeinheit so vertauscht werden, daß das Standardlaufwerk kein Diskettenlaufwerk sondern die Festplatte ist, auf der sich das gesicherte UNIX- artige Betriebssystem befindet. Außerdem muß jedes Softwaremodul, das ab dem Zeitpunkt ausgeführt wird, an dem die Systemeinheit eingeschaltet wird, ein gesichertes Softwaremodul sein. Der Nur- Lese-Speicher muß ein, gesichertes Softwaremodul sein und ist als ein Teil der Computersicherheitsbasis zu betrachten. Aller Code, der beim Laden des gesicherten UNIX-artigen Betriebssystems ausgeführt wird, wird als Teil der Computersicherheitsbasis betrachtet. Unter diesen Vorbehalten kann der Benutzer mit Sicherheit annehmen, daß er beim Booten seines Betriebssystems mit einem gesicherten Zustand zu arbeiten beginnt.
In Tabelle I ist der erfindungsgemäße Init-Prozeß als Pseudo- Code wiedergegeben. Der Pseudo-Code in Tabelle 1 zeigt die Punkte des Init-Prozesses, die die Sicherheitsanforderungstaste betreffen. Fig. 21 ist ein Flußdiagramm des Pseudo-Codes in Tabelle 1. Init ist eine Schleife, die so lange wartet, bis ein Prozeß endet. Welche Handlungen init vornimmt, hängen davon ab, wie dieser Prozeß endete und welcher Prozeß endete. Der erste Ausdruck in Tabelle 1 ist das Warten auf das Ende eines Prozesses. Es gibt tatsächlich vier Fälle: der Prozeß kann entweder aufgrund des SIGSAK-Signals oder normal enden. Endet er durch das SIGSAK-Signal, könnte es entweder der Prozeß getty oder der Prozeß login sein, oder es könnte ein gerade laufender Benutzerprozeß eines bereits angemeldeten Benutzer sein. Falls der Prozeß normal beendet wird, könnte es sich um die gesicherte Shell oder um irgendeinen anderen Prozeß handeln. Es gibt vier Vorgehensweisen von init, die davon abhängen, welcher Prozeß beendet worden ist. Falls der Prozeß normal geendet hat und es sich nicht um die gesicherte Shell gehandelt hat, dann erzeugt init lediglich eine neue Kopie von getty. Das wäre dann der Fall, wenn sich ein Benutzer vom System abgemeldet hat. Der Benutzer arbeitet zur Zeit unter einer Shell, er meldet sich ab, und diese Shell wird beendet. Wird diese Shell beendet und init dies in dem ersten Ausdruck von Tabelle 1 feststellt und zu dem Ergebnis kommt, daß der Prozeß normal geendet hat und keine gesicherte Shell war, dann erstellt init eine neue Kopie von getty, die eine neue Anmeldeaufforderung ausgibt. Dies ist der Fall einer normalen Abmeldung.
Für den Fall, daß der Benutzer die Sicherheitsanforderungstaste gedrückt hat, bevor er sich angemeldet hat, hat der Benutzer zwar bereits eine Anmeldeaufforderung, mißtraut ihr aber und möchte die Sicherheitsanforderungstaste drücken. In diesem Fall stellt init fest, daß der Prozeß durch das Drücken der Sicherheitsanforderungstaste beendet wurde, und prüft dann, um welche Art von Prozeß es sich dabei gehandelt hat. Entweder war es getty oder es war login. In diesem Fall führt init einen neuen Probeprozeß aus. Init führt Operationen durch, die jeglichen Zugriff auf die Datenstation des Benutzers, den andere Prozesse möglicherweise haben, wirksam unterbricht. Zu diesem Zweck ändert Init den Zugriffsmodus für die Datenstation des Benutzers so, daß nur der Besitzer lesen und schreiben darf, ändert die Besitzverhältnisse der Datenstation aufroot und nimmt den Zugriff auf die Datenstation mit dem Befehl vhangup wieder zurück. Init führt dann den Systemaufruf exec durch, um eine weitere Kopie des Programms getty darüberzuladen. Wenn der Benutzer die Sicherheitsanforderungstaste drückt und dabei abgemeldet ist, stellt init dies fest, bereinigt sicherheitshalber die Umgebung und erstellt eine neue Kopie von getty.
Beim nächsten Fall hat sich der Benutzer bereits angemeldet, wenn er die Sicherheitsanforderungstaste drückt. In diesem Fall führt er entweder gerade einen gewöhnlichen Prozeß aus oder er besitzt bereits eine gesicherte Shell. In beiden Fällen bereinigt init die Umgebung und richtet eine gesicherte Shell für ihn ein. Init erzeugt über den Systemaufruf fork ein neues Kind, das Kind ändert den Zugriffsmodus der Datenstation des Benutzers, so daß sonst niemand Zugriff auf die Datenstation hat, ändert die Besitzerkennung und nimmt den Zugriff mittels des Befehls vhangup zurück und hält dann in der Datei /etc/utmp die Tatsache fest, daß das Kind nun die gesicherte Shell ausführt und führt dann einen Systemaufruf exec aus, um die gesicherte Shell zu überlagern. Auf diese Weise wird der Sicherheitsweg eingerichtet.
Der nächste Fall ist die Art und Weise, wie die gesicherte Shell beendet wird. Angenommen, der Benutzer arbeitet jetzt unter der gesicherten Shell, ist damit fertig und drückt Abbruchtasten, zum Beispiel Control D. Wenn das passiert, stellt init oben in der Schleife in Tabelle 1 fest, daß ein Prozeß beendet worden ist, aber diesmal mit normalem Ende, weil der Benutzer Control D gedrückt hat. Init sieht nach, wer beendet wurde, und sieht, daß es die gesicherte Shell war. Statt den Benutzer abzumelden, erzeugt mit eine neue, nicht gesicherte Shell. Daher stellt init die Anmeldeumgebung wieder her, speichert in der Datei /etc/utmp einen Datensatz, der hauptsächlich festhält, daß das Kind nun eine nicht gesicherte Shell ausführt, führt dann den Systemaufruf fork aus und lädt anschließend mittels des Systemaufrufs exec eine nicht gesicherte Shell darüber. Somit gibt es vier Situationen. Init wartet auf das Ende eines Prozesses und ermittelt dann, welche der vier Situationen tatsächlich passiert ist, und führt jene Operationen für jene vier Situationen aus.
Die Folge der Fig. 8-20 kann nun hinsichtlich der Arbeitsweise des erfindungsgemäßen Init-Prozesses, wie er zuvor im Zusammenhang mit Tabelle 1 beschrieben worden ist, rückblickend überschaut werden. Fig. 8 ist ein Zustandsdiagramm, das einen von drei Zuständen zeigt, in denen sich ein Prozeß befinden kann. Zustand 1 ist vor der Anmeldung, wenn der Benutzer mit dem echten Anmeldeprogramm kommuniziert. Zustand 2 ist der Zustand, in den der Benutzer übergeht, unmittelbar nachdem er sich erfolgreich angemeldet hat, aber noch bevor er zum erstenmal die Sicherheitsanforderungstaste benutzt hat; Zustand 3 liegt schließlich vor, wenn der Benutzer tatsächlich in der gesicherten Shell ist, nachdem er die Sicherheitsanforderungstaste gedrückt hat. Nehmen wir an, ich sei der Benutzer und beginne im Zustand S1 und kommuniziere mit dem echten Anmeldeprogramm. Dann kann ich eines von zwei Dingen tun; ich kann mich entweder erfolgreich anmelden oder ich kann die Sicherheitsanforderungstaste drücken. Falls ich die Sicherheitsanforderungstaste drücke, gelange ich unverzüglich wieder in Zustand 1 zurück. Mit anderen Worten, ich bleibe im Zustand vor der Anmeldung. Wenn ich dagegen meinen Namen und ein richtiges Kennwort angebe, habe ich mich mit Erfolg angemeldet und gelange in Zustand S2, was bedeutet, daß ich nun eine gewöhnliche (nicht gesicherte) Shell habe und mich in einer normalen Umgebung befinde. Im Zustand S2 kann ich all meine normale, nicht gesicherte Arbeit tun und bleibe auch in diesem Zustand, wenn ich meine normale Arbeit tue. Wenn ich jedoch in die gesicherte Shell möchte, dann drücke ich die Sicherheitsanforderungstaste. Wenn ich die Sicherheitsanforderungstaste drücke, gelange ich vom Zustand S2 in den Zustand S3, die gesicherte Shell. Selbst wenn ich wiederholt die Sicherheitsanforderungstaste drücke, bleibe ich im Zustand S3. Mit anderen Worten, ich bleibe im Zustand 53, sobald ich im Zustand S3 bin und die Sicherheitsanforderungstaste wiederholt drücke. Durch Drücken von Control D oder durch ein normales Prozeßende gelange ich wieder in einen der vorherigen Zustände zurück. Wenn ich also in der gesicherten Shell bin und normal mit Control D beende, kehre ich in die gewöhnliche, nicht gesicherte Shell zurück; von dort kehre ich durch Drücken von Control D in den ersten Zustand, den Abmeldezustand, zurück.
Wenden wir uns Fig. 9 zu, in der wir die Abfolge der Prozesse zeigen, wie sie erstellt und zerstört werden. Anfangs, wenn das System hochgefahren wird, gibt es einen Einzelprozeß init, und init ist der höchstrangigste Elternprozeß aller Prozesse im System. Fig. 9 zeigt unseren Anfangszustand, und Fig. 10 zeigt, was passiert, wenn init den allerersten Prozeß erzeugt. In diesem Fall ist das "getty", und getty ist der Prozeß, der am Anfang die Anmeldeaufforderung auf dem Bildschirm ausgibt. Diese gibt den Namen der Maschine und die Anmeldeaufforderung "login" aus. Dieser Prozeß ist in erster Linie dafür verantwortlich, die Datenstation abzufragen und zu ermitteln, mit welcher Übertragungsgeschwindigkeit die Datenstation arbeitet, und den Namen des Benutzers zu lesen, der sich anmelden möchte.
Fig. 11 zeigt, was geschieht, nachdem getty mit Erfolg den Namen des Benutzers gelesen hat und die richtige Geschwindigkeit der Datenstation ermittelt hat: es überlagert sich dann selbst durch den Aufruf von exec und die Aufforderung an das System, das Anmeldeprogramm auszuführen. Das Anmeldeprogramm ist nun hauptsächlich dafür verantwortlich, die Berechtigung des Benutzer zu überprüfen. Anders ausgedrückt, verlangt es vom Benutzer ein Kennwort und vergleicht dieses Kennwort oder es verschlüsselt das Kennwort und vergleicht das verschlüsselte Kennwort mit einer verschlüsselten Liste von Kennworten, die sich in einer der Systemdateien, der Datei /etc/passwd, befinden. Falls es eine Übereinstimmung gibt, ist die Anmeldung erfolgreich, und wir kommen zu Fig. 12. Ist sie nicht erfolgreich, fragt das Anmeldeprogramm wiederholt nach dem Namen des Benutzers und dessen Kennwort.
Falls die Anmeldung erfolgreich war, gelangt man zu Fig. 12, wo sich das Anmeldeprogramm mit der Shell überlagert, indem "exec" mit dem Namen der Shell aufgerufen wird. An dieser Stelle haben wir nun den Elternprozeß init, dessen unmittelbarer Nachkomme die Shell oder den Befehlsinterpreter für UNIX ausführt. In diesem Zustand kann der Benutzer seine normale Arbeit erledigen, was Zustand S2 in Fig. 2 entspricht. Nehmen wir an, daß der Benutzer nun zur gesicherten Shell übergehen möchte.
Fig. 13 zeigt drei Stufen. Die erste Stufe zeigt init mit der Shell, und dann wird, falls der Benutzer die Sicherheitsanforderungstaste drückt, als allererstes die Shell beendet. Wenn die Shell beendet ist, läuft wieder init selbst und stellt das Ende der Shell fest und erzeugt an deren Stelle die gesicherte Shell. Nun sind wir im Zustand 53, wo der Benutzer seine Arbeit in der gesicherten Shell erledigen kann. Dadurch wird der Sicherheitsweg eingerichtet.
Einzelheiten darüber, wie der Sicherheitsweg eingerichtet wird, befinden sich im Pseudo-Code. Fig. 13 zeigt init mit der Shell "SH". Falls der Benutzer die Sicherheitsanforderungstaste drückt, wird dadurch die Shell beendet. Dem Pseudo-Code in Tabelle 1 läßt sich entnehmen, daß init auf das Ende eines Prozesses wartet, der Prozeß durch SIGSAK beendet worden ist und der Prozeß in diesem Fall ein Benutzerprozeß oder eine Shell war. Daher dienen die Schritte, die init zur Einrichtung des Sicherheitswegs unternimmt, zur Verzweigung zu einem neuen Kindprozeß, der zwischen dem zweiten und dritten Schritt in Fig. 13 dargestellt ist; dabei geht das System von init zu init mit dem Kind. Der Sicherweitsweg wird eingerichtet, indem der Zugriffsmodus der Benutzerdatenstation so geändert wird, daß nur der Besitzer lesen und schreiben darf, die Besitzerkennung und die Gruppenkennung der Datenstation in root geändert werden und der Zugriff auf die Datenstation mit dem Befehl vhangup rückgängig gemacht wird. Durch diese Schritte wird der Sicherheitsweg eingerichtet. Init hält dann in der Datei /etc/utmp fest, daß das Kind die gesicherte Shell ausführt, und init ruft über exec die gesicherte Shell auf, was den letzten Schritt in Fig. 13 darstellt.
Von Fig. 13 ausgehend, nehmen wir an, daß der Benutzer nun ein paar Befehle in der gesicherten Shell ausführen möchte. Falls der Benutzer beispielsweise sein Kennwort ändern möchte, gibt er den Befehl password ein, was den ersten in Fig. 14 dargestellten Übergang erzeugt; dort haben wir nun init, wobei die gesicherte Shell dessen unmittelbarer Nachkomme und der Befehl password der darunter befindliche Nachkomme ist. Wenn dann dieser Befehl password endet, kehren wir in die Situation zurück, in der wir nur init und die gesicherte Shell haben. In Fig. 14 ist dargestellt, daß die gesicherte Shell ausgeführt wird, der Befehl ausgegeben und ausgeführt wird und daß man dann zur gesicherten Shell zurückkehrt.
Um zu Fig. 15 zu kommen, wollen wir annehmen, daß der Benutzer die gesicherte Shell nicht länger benutzen und zur gewöhnlichen Shell zurückkehren möchte. Dieses Bild zeigt, was geschieht, wenn wir vom Zustand S3 in den Zustand S2 im ursprünglichen Zustandsdiagramm in Fig. 8 gelangen. Falls der Benutzer in der gesicherten Shell Control D drückt, wird die gesicherte Shell beendet, und init stellt die nicht gesicherte Shell wieder her. Bezug nehmend auf den Pseudo-Code in Tabelle 1 beginnt init wieder oben in der Schleife und wartet auf das Ende eines Prozesses; wenn init das Ende eines Prozesses feststellt, untersucht es, unter welchen Umständen dieser Prozeß beendet wurde. Da der Benutzer die gesicherte Shell normal verlassen hat, geht init zu der Anweisung, daß der Prozeß normal beendet wurde. Dann prüft init den Typ des beendeten Prozesses. In diesem Fall ist das die gesicherte Shell. Init führt also drei Schritte aus. Als erstes erstellt init wieder die Anmeldeumgebung, d. h. init erzeugt einen Prozeß mit dieser ganz bestimmten Benutzerkennung und reinitialisiert die Umgebung so, wie sie bei der Anmeldung des Benutzers war. Init hält in der Datei /etc/utmp fest, daß das Kind jetzt keine gesicherte, sondern eine nicht gesicherte Shell ausführt, und dann führt init die Systemaufruffolge exec-fork aus, um eine nicht gesicherte Shell darüberzulegen, und damit sind wir beim dritten Schritt in Fig. 15.
Fig. 16 zeigt ein Beispiel dafür, wie die Shell "SH" mehrere Prozesse unter sich ausführt. Nachdem sich beispielsweise ein Benutzer angemeldet hat - ob er nun eine gesicherte Shell hat oder eine normale Shell hat - und Befehle erteilt, werden Prozesse erzeugt, die direkte Nachkommen dieser Shell sind, so daß man auf den ersten Blick sieht, daß eine Shell "SH" ein Kalkulationsprogramm ausführt und daß dieses wiederum eine weitere Sub- Shell SH erzeugt hat, um andere Befehle des Betriebssystems auszuführen. Ein zweiter Blick auf Fig. 16 zeigt init mit der Shell SH und einem Prozeßbaum, der beliebig viele Prozesse repräsentiert, die von dieser einen Shell aus ausgeführt werden.
Fig. 17 zeigt, was geschieht, wenn der Benutzer die Sicherheitsanforderungstaste drückt und es mehr als nur die Shell SH gibt. Anders ausgedrückt, nehmen wir an, daß wir als Benutzer in der normalen, nicht gesicherten Shell arbeiten und eine ganze Reihe von Programmen, z. B. diverse Anwendungsprogramme, laufen haben und dann die Sicherheitsanforderungstaste drücken. Fig. 17 ist zu entnehmen, daß nicht nur die Shell SH beendet wird, sondern daß alle Prozesse, die unter der Shell SH ablaufen, d. h. alle Anwendungsprogramme, ebenfalls beendet werden.
Fig. 18 zeigt den Zusammenhang zwischen einer Reihe von Prozessen und einer Datenstation, wobei spezielle Beispiele für möglicherweise ablaufende Prozeßtypen dargestellt werden. Fig. 18 zeigt eine Shell SH mit einem Kalkulationsprogramm und einem Datenbankprogramm, und das Datenbankprogramm möge irgendein als Trojanisches Pferd arbeitendes Programm ausgeführt haben. All diese Programme sind mit einer ganz bestimmten Datenstation verbunden und kommunizieren mit dieser. Wenn der Benutzer nun die Sicherheitsanforderungstaste drückt, werden sofort die Shell, das Kalkulationsprogramm, das Datenbankprogramm und das Trojanische Pferd beendet, und statt dessen wird die gesicherte Shell TSH eingerichtet, die nun mit der Datenstation verbunden ist. Wenn der Benutzer die gesicherte Shell nicht länger braucht und in Fig. 20 Control D drückt, entfernt init die gesicherte Shell und stellt an ,deren Stelle die gewöhnliche, nicht gesicherte Shell, die nun mit der Datenstation verbunden ist.

TABELLE 1

Init:
Warte auf das Ende eines Prozesses;
falls Prozeß aufgrund SIGSAK endete, dann falls Prozeß getty oder login war, dann verzweige zu neuem Kindprozeß;
Kind ändert Zugriffsmodus der Datenstation, so daß nur der Besitzer schreiben und lesen kann;
Kind ändert die Besitzerkennung und die Gruppenkennung der Datenstation in root und nimmt den Zugriff auf die Datenstation mit vhangup zurück;
Kind führt das Programm getty aus;
andernfalls, falls der Prozeß ein Benutzerprozeß oder TSH war, dann
verzweige zu neuem Kindprozeß;
Kind ändert Zugriffsmodus der Datenstation, so daß nur der Besitzer schreiben und lesen kann;
Kind ändert die Besitzerkennung und die Gruppenkennung der Datenstation in root und nimmt den Zugriff auf die Datenstation mit vhangup zurück;
schreibe in /etc/utmp, daß das Kind TSH ausführt;
führe gesicherte Shell (TSH) aus;
Ende falls
andernfalls, falls der Prozeß normal beendet wurde, dann falls der Prozeß TSH war, dann
erzeuge Anmeldeumgebung neu;
schreibe in /etc/utmp, daß das Kind in gesicherter Shell läuft;
verzweige zu nicht gesicherter Shell/führe diese aus
andernfalls
verzweige zu neuer Kopie von getty/führe diese aus Ende falls
Ende der Schleife.
Der hier beschriebene Sicherheitswegmechanismus für ein Betriebssystem stellt einen Sicherheitswegmechanismus zur Verfügung, der unberechtigte Programme daran hindern kann, Daten einer Benutzerdatenstation zu lesen. Der Sicherheitswegmechanismus stellt sicher, daß die über die Tastatur einer Datenstation von einem Benutzer eingegebenen Daten vor einem eventuellen Eindringen durch unberechtigte Programme geschützt sind. Der Sicherheitswegmechanismus ermöglicht dem Benutzer die Einrichtung eines fälschungssicheren und einbruchssicheren Kommunikationspfads zwischen seiner Datenstation und der Software des gesicherten Betriebssystems.

Claims

1. Verfahren in einem UNIX-artigen Betriebssystem zur Einrichtung eines Sicherheitswegs zwischen einer Datenstation, die mit einem Datenprozessor verbunden ist, der einen Init- Prozeß unter dem Betriebssystem ausführt, und einem gesicherten Shell-Bereich einer Computersicherheitsbasis in dem Datenprozessor als Reaktion auf eine Sicherheitsanforderung, das folgende Schritte umfaßt:

Prüfen, ob ein bestehender Prozeß, der unter der Steuerung des Init-Prozesses abläuft, beendet worden ist;

Ausführen des Systemaufrufs fork zur Erzeugung eines neuen Kindprozesses durch den Init-Prozeß, wenn der bestehende Prozeß aufgrund der Sicherheitsanforderung endet;

Ändern des Zugriffsmodus der Datenstation, so daß nur der Besitzer lesen und schreiben kann;

Ändern der Besitzerkennung der Datenstation in root;

Rücknahme des Zugriffs auf die Datenstation;

Aufzeichnen, daß der Kindprozeß eine gesicherte Shell ausführt;

Ausführen des Systemaufrufs exec, um die gesicherte Shell über den neuen Kindprozeß zu legen, wodurch ein Sicherheitsweg eingerichtet wird.

2. Verfahren in einem UNIX-artigen Betriebssystem zur Einrichtung eines Sicherheitswegs zwischen einer Datenstation, die mit einem Datenprozessor verbunden ist, der einen gesicherten Init-Prozeß unter dem Betriebssystem ausführt, und einem gesicherten Shell-Bereich einer Computersicherheitsbasis in dem Datenprozessor als Reaktion auf eine Sicherheitsanforderung, das folgende Schritte umfaßt:

Warten auf die Beendigung eines bestehenden Prozesses, der unter der Steuerung des gesicherten Init-Prozesses abläuft;

Ausführen des Systemaufrufs fork durch den gesicherten Init- Prozeß, wenn der bestehende Prozeß aufgrund einer Sicherheitsanforderung beendet worden ist und der bestehende Prozeß getty oder login war, Ändern des Zugriffsmodus der Datenstation, so daß nur der Besitzer lesen und schreiben kann, Ändern der Besitzerkennung und der Gruppenkennung der Datenstation in root, Rücknahme des Zugriffs auf die Datenstation, Ausführen des Systemaufrufs exec, um den Prozeß getty über den neuen Kindprozeß zu legen, und Ausführen des Prozesses getty;

Ausführen des Systemaufrufs fork zur Erzeugung eines neuen Kindprozesses durch den gesicherten Init-Prozeß, wenn der bestehende Prozeß aufgrund einer Sicherheitsanforderung beendet worden ist und der bestehende Prozeß ein Benutzerprozeß oder eine gesicherte Shell war, Ändern des Zugriffsmodus der Datenstation, so daß nur der Besitzer lesen und schreiben kann, Ändern der Besitzerkennung und der Gruppenkennung der Datenstation in root, Rücknahme des Zugriffs auf die Datenstation, Aufzeichnen, daß das Kind eine gesicherte Shell ausführt, und Ausführen des Systemaufrufs exec, um eine gesicherte Shell über den Kindprozeß zu legen, wodurch ein Sicherheitsweg eingerichtet wird;

Ausführen des Systemaufrufs fork zur Erzeugung eines neuen Kindprozesses durch den gesicherten Init-Prozeß, wenn der bestehende Prozeß normal beendet worden ist und der bestehende Prozeß eine gesicherte Shell war, Aufzeichnen, daß der neue Kindprozeß eine nicht gesicherte Shell ausführt, Ausführen des Systemaufrufs exec, um eine nicht gesicherte Shell über den neuen Kindprozeß zu legen;

Ausführen des Systemaufrufs fork zur Erzeugung eines neuen Kindprozesses durch den gesicherten Init-Prozeß, wenn der bestehende Prozeß normal beendet worden ist und der bestehende Prozeß kein gesicherter Prozeß war, Ausführen des Systemaufrufs exec, um den Prozeß getty über den Kindprozeß zu legen, um eine Anmeldefunktion für eine neue Sitzung an der Datenstation zur Verfügung zu stellen.

3. Verfahren gemäß Anspruch 2, bei dem die Sicherheitsanforderung durch ein UNIX-artiges Betriebssystem als SIGSAK-Unterbrechungssignal erkannt wird.

4. Verfahren gemäß Anspruch 3, bei dem eine beliebige benutzerdefinierte Tastenkombination, die an der Datenstation eingegeben wird, als die Sicherheitsanforderung eingesetzt werden kann.

5. Verfahren gemäß Anspruch 4, bei dem für die Erzeugung einer vollständigen Sicherheitsanforderungssequenz ein Zeitlimit eingerichtet ist, wobei gewählte Tasten nach dem Zeitlimit als normale Tasten der Datenstation verwendet werden können.

6. Verfahren gemäß Anspruch 5, bei dem die Anfangstaste in einem Leitungsdisziplintreiber gepuffert wird und nicht an einen Anwendungsprozeß geschickt wird, bis die Sequenz endet oder das Zeitlimit für die Sicherheitsanforderung abläuft, wodurch die Emulation eines Sicherheitswegs durch unberechtigte Programme verhindert wird.

7. Verfahren in einem UNIX-artigen Betriebssystem in einem Datenverarbeitungssystem mit einem Speicher, an dem eine Vielzahl von Datenstationen angeschlossen ist, wobei mindestens eine Datenstation eine Sicherheitsanforderungstaste besitzt, um als Reaktion auf die Sicherheitsanforderungstaste einen Sicherheitsweg zwischen der Datenstation und einem gesicherten Shell-Bereich einer Computersicherheitsbasis einzurichten, der ein Kindprozeß eines Init-Prozesses unter dem Betriebssystem ist, wobei das Verfahren folgende Schritte umfaßt:

Feststellen der Sicherheitsanforderungstaste in einem mit der Tastatur verbundenen Tastatur-Gerätetreiber;

Ausgabe der Information, daß die Sicherheitsanforderungstaste festgestellt worden ist, vom Tastatur-Gerätetreiber an einen Generator für das Sicherheitsanforderungstasten- Signal;

Ausgabe eines SIGSAK-Signals durch den Generator für das Sicherheitsanforderungstasten-Signal an alle Prozesse, die in einer Prozeßgruppe der Datenstation arbeiten, das alle Prozesse in der Prozeßgruppe der Datenstation beendet;

Zuführen des SIGSAK-Signals an Zugriffsberechtigungstabellen, die zu allen an die Datenstation angeschlossenen Gerätetreibern gehören, um allen Prozessen in dem Datenverarbeitungssystem außer dem Init-Prozeß die Zugriffsberechtigung zu verweigern;

Zuführen des SIGSAK-Signals an eine Dateizugriffstabelle, um alle Adreßinformationen zu entfernen, die die an die Datenstation angeschlossenen Gerätetreiber mit allen Prozessen in dem Datenverarbeitungssystem außer dem Init-Prozeß verknüpfen;

Ausführen des Systemaufrufs fork zur Erzeugung eines neuen Kindprozesses durch den Init-Prozeß;

Ausführen des Systemaufrufs exec, um eine gesicherte Shell über den neuen Kindprozeß zu legen, wobei der gesicherte Shell-Prozeß Zugriffsberechtigung auf die an die Datenstation angeschlossenen Gerätetreiber hat und wobei der gesicherte Shell-Prozeß eine in der Dateizugriffstabelle definierte Adressenverknüpfung mit den an die Datenstation angeschlossenen Gerätetreibern hat;

wodurch zwischen der Datenstation und dem gesicherten Shell- Prozeß ein Sicherheitsweg eingerichtet wird.