DE69132809T2

DE69132809T2 - Verfahren und Anordnung zur Ausführung von Sicherheitswegbefehlen

Info

Publication number: DE69132809T2
Application number: DE69132809T
Authority: DE
Inventors: Casey, Jr.; Morrie Gasser; Judith Shellhorse Hall; Clifford Earl Kahn; Leslie Richard Kendall; Steven B. Lipner; Andrew Halstead Mason; Paul Douglas Saywer; Mary Ellen Zurko
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1990-02-13
Filing date: 1991-02-13
Publication date: 2002-05-29
Anticipated expiration: 2011-02-14
Also published as: EP0443423B1; DE69132809D1; US6507909B1; US20050097354A1; EP0443423A3; US7036022B1; US6871283B1; EP0443423A2; CA2036257A1; AU7103191A; GB9103055D0

Description

Diese Erfindung betrifft Techniken für die Verbesserung der Sicherheit in einem Computersystem. Insbesondere betrifft diese Erfindung ein Verfahren, eine Vorrichtung und ein Computerprogrammprodukt zur Implementierung gesicherter Befehle, sowohl durch gesicherten als auch ungesicherten Code.
Die starke Verbreitung von Computern hat zu einem Bedarf nach zuverlässigen Computersicherheitssystemen geführt. Die Notwendigkeit bestimmte Informationen zu schützen ist beispielsweise in Bereichen der nationalen Sicherheit groß. Sicherheitsmaßnahmen sind auch auf anderen Gebieten, einschließlich Gebieten, welche Finanz-, Medien- und Personen-Information nutzen, erforderlich. Viele computerisierte Informationssysteme enthalten interne Sicherheitsmaßnahmen, welche dem Benutzern unterschiedliche Zugriffsstufen zu computerisierter Information bieten, und welche zumindest einen gewissen Grad von Schutz der Information vor unerwünschten Zugriffen bereitstellen.
Der Stand der Technik umfasst die nachstehenden Veröffentlichungen bezüglich der Verbesserung der Sicherheit von Computersystemen.
Das U. S. Patent 4,918,653 schlägt einen Mechanismus eines gesicherten Weges für ein Betriebssystem vor, um "Trojanische-Pferd"-Programme auszuschließen. Durch Drücken einer Sicherheitstaste (SAK - Secure Attention Key) auf einer Terminaltastatur kann der Benutzer einen gesicherten Weg zwischen dem Terminal und einem gesicherten Schalenabschnitt einer gesicherten Computerbasis (TCB - Trusted Computing Base) eines Unix-Betriebssystems erzeugen. Wenn ein SAK-Signal von dem Zentralrechner, bzw. Host empfangen wird, beendet der Host alle Prozesse in der Prozessgruppe des Terminals; entfernt im wesentlichen die gesamte Adressierungsinformation, welche die Gerätetreiberschnittstellen des Terminals betreffen aus dem Datenverarbeitungssystem; und führt einen neuen Tochterprozess und einen gesicherten Schalenprozess aus.
Das U. S. Patent Nr. 4,797,853 schlägt eine direkte Speicherzugriffssteuerung vor, welche den Zugriff auf den Speicher steuert, und das Passieren von Daten nur während eines einzigen Taktzyklusses erlaubt. Wenn die Steuerung als Busmaster arbeitet, veranlasst sie die Erzeugung eines von drei Zugriffssignalen, welche den Zugriffsbereich der Steuerung bestimmen. Versuche den Speicherraum ohne Zugriffserlaubnis zu adressieren, führen zu der Erzeugung eines Fehlersignals.
Das U. S. Patent Nr. 4,754,326 schlägt ein Verfahren zur Verhinderung eines nicht autorisierten Zugriffes auf ein Computersystem durch die Anwendung einer Prüfung zur Ermittlung der Benutzerautorisierung verbunden mit der Auswahl von Parametern durch den Benutzer vor. Es wird ein "Verriegelungs"-Merkmal verwendet, wodurch jeder Benutzer des Systems ein Passwort mit eins bis sechs Buchstaben verwendet, welches das System "verriegelt". Ein weiterer Benutzer, welcher einen Zugriff auf die Suchtdateien oder dergleichen eines ersten Benutzers versucht, muss zuerst das selektierte Passwort des ersten Benutzers eingeben. Das Passwort muss zweimal eingetippt werden, um eine zufällige Eingabe des falschen Passwortes zu verhindern. Das U. S. Patent Nr. 4,751,669 schlägt eine Videotext-Dekodierungsvorrichtung vor, welche unter anderem dafür verwendet wird, eine einfache Einlog- und Auslogprozedur für Videotextbenutzer bereitzustellen. Bestimmte Kommandos (z. B. Ausloggen) erfordern die Bestätigung durch den Benutzer, bevor sie ausgeführt werden.
Das U. S. Patent Nr. 4,677,546 und das U. S. Patent Nr. 4,669,043 schlagen eine Speicherzugriffssteuerung (MAC) vor. Die MAC steuert den Zugriff zu der Speicherhierarchie. U. S. 4,677,546 schlägt ein Verfahren vor, wodurch auf geschützte Codedaten durch eine Neudefinition von Bereichen eines Adressenraums mit Bezugstoren vor.
Die Dunford "FILER (Version 2.20) " Benutzerdokumentation beschreibt ein FILER-Programm (Dateiverwaltungsprogramm), welches vor dem Prioritätsdatum dieser Anmeldung in dem öffentlich zugänglichen Informationsdienst von CompuServe verfügbar war. Das FILER-Programm wiederholt möglicherweise gefährliche Benutzerbefehle und fordert vor der Ausführung eine Bestätigung von dem Benutzer. Beispielsweise kann der Benutzer das FILER-Programm anweisen, eine Gruppe von Dateien unter Verwendung von sogenannten "Wild- Card"-Bezeichnern ("DEL*.*") zu löschen. Vor der Ausführung des Befehls gibt das Programm eine Liste der mit dem Wild-Card-Bezeichner übereinstimmenden spezifischen Dateien auf, welche gelöscht werden und bittet um eine Bestätigung, dass die Dateien gelöscht werden sollen. Die Befehlszeilenoption /S des Programms erlaubt es dem Benutzer selektiv die Löschung einzelner Dateien, welche dem Wild- Card-Bezeichner entsprechen, zu bestätigen.
Unix-Betriebssystem (kein spezifisches Referenzdokument). In vielen Unix-Systemen würden sich eine Reihe einfacher Shell-Befehle direkt als Systemaufrufe aus. Dieses Merkmal ist gut dokumentiert. Beispielsweise entspricht der Befehl "rm" dem Systemaufruf "unlink" und führt zu der Entfernung einer Datei. Der Befehl "rmdir" entspricht dem Systemaufruf "rmdir" und führt zu der Löschung eines Verzeichnisses. Der Befehl "chmod" entspricht dem Systemaufruf "chmod" und führt zu einer Veränderung in dem Schutzmodus einer Datei.
Diese Systemaufrufe könnten als "gesichert" betrachtet werden. Ein Systemaufruf von Unix führt seine Arbeit im Kernmodus aus. Der Aufruf führt etwas aus, was ein in einem nicht privilegierten Bereich laufendes nicht privilegiertes Programm nicht ausführen könnte. Beispielsweise kann in einem nicht privilegierten Bereich laufendes nicht privilegiertes Programm nicht auf die Dateistruktur schreiben. Trotzdem können die vorstehend erwähnten Systemaufrufe alle von nicht privilegierten Programmen, welche zugunsten nicht privilegierter Benutzer laufen, verwendet werden. Derartige Programme können als "ungesichert" betrachtet werden. Die Programme "rm", "rmdir" und "chmod" selbst sind auf vielen Unix-artigen Systemen, wie z. B. einem von Digital Equipment Corporation ermittelten Ultrix-System nicht privilegiert.
Somit enthält der Stand der Technik ein ungesichertes Programm, welches eine Syntaxanalyse eines Befehls durchführt, und dann den Befehl ausführt, indem ein gesicherter Dienst aufgerufen wird, welcher die Ausführung in einer gesicherten Rechnerumgebung, nämlich in dem Kernmodus durchführt.
Mcauley und Drongowski, KSOS, The Design of a Secure Operatine System, wurde (vermutlich) etwa um 1979 veröffentlicht. Das Papie r diskutiert ein DOD Kernalized Secure Operating System (KSOS), welches sich anscheinend zu dieser Zeit in der Entwicklung befand. Das Kapitel 3.1 diskutiert das Sicherheitskernkonzept; das Kapitel 3.1.1 enthält eine Hintergrunddiskussion des gesicherten Prozesses. Das Kapitel 3.1.5 beginnend auf Seite 9 diskutiert eine vorgeschlagene sichere Terminalschnittstelle, einschließlich des Konzeptes der Blockierung des normalen Weges, wenn der Terminalbenutzer eine reservierte Sondertaste, wie z. B. BREAK-Taste drückt. Fig. 2 des Papiers veranschaulicht den Vorschlag.
Ames, Gasser und Shell, "Security Kernel Design and Implementation: An Introduction" IEEE Computer, Juli 1983, pp. 14-22, stellt eine nützliche Hintergrunddiskussion von Sicherheitskernen bereit.
EP-A-326699 offenbart ein Datenverarbeitungsnetz mit einem Prozessor bei einem Serverknoten, welcher einen nicht gesicherten Prozess fahren kann, und ferner mit einer Einrichtung für einen Aufbau eines gesicherten Weges zwischen einem Datenprozessor eines Clientknoten und einem gesicherten Prozess in dem Prozessor bei dem entfernten Serverknoten versehen ist.
Das IEEE SYMPOSIUM ON SECURITY AND PRIVACY, April 988, OAKLAND, US, pages 147-155, 5. WIESEMANN ET AL., "The Trusted Path between SMITE and the User" offenbart eine Methodologie für den Betrieb von Signalkanälen nur über einen gesicherten Weg, welcher die gesamte Software umfasst, welche ausgeführt werden muss, damit die Wünsche des menschlichen Benutzers aufgerufen werden. Einschränkungen bestehen darin, dass die Sicherheitsweg-Softwarefunktion, welche befolgt werden muss, die gewählte sein muss, und ebenso für die Objekte bestimmt sein muss, für welche die Funktion angewendet wird. Ferner darf die Software nicht eine Funktion initialisieren, sofern sie nicht von dem menschlichen Benutzer dazu angewiesen wird.

Sicherheitskriterien; Bezugsvalidierungssysteme

Als Antwort auf den Bedarf nach sicheren Computersystemen hat das Verteidigungsministerium eine Veröffentlichung mit dem Titel DeQartement of Defense Trusted ComDutersystem Evaluation Criteria (Referenznummer DOD 5200.28-STD.) herausgegeben. Diese Veröffentlichung wird manchmal als das "Orange Book" bezeichnet, und ist von dem Verteidigungsministerium erhältlich. Das Orange Book beschreibt Systemsicherheitsaufgaben und Evaluierungskriterien für sichere Computersysteme.
Ein "sicheres" Computersystem enthält im allgemeinen eine Art eines "Referenzvalidierungs"-Systems. Diese (als Referenzmonitore" bekannten Referenzvalidierungssysteme sind für die Durchsetzung der Sicherheitsregeln (Sicherheitsstrategie) für ein gegebenes Computersystem verantwortlich.
Referenzmonitore vermitteln alle Zugriffe auf "Objekte" von "Subjekten". Objekte sind passive Einheiten, welche Information enthalten oder empfangen. Ein Zugriff auf ein Objekt impliziert den Zugriff auf die Information, die es enthält. Subjekte sind aktive Einheiten, im allgemeinen in der Form einer Person, eines Prozesses oder einer Vorrichtung, welche einen Informationsfluss zwischen Objekten bewirken oder den Systemzustand verändern. Ein Subjekt kann sich normalerweise auf seine eigene, subjektinterne Information ohne die Einbeziehung des Referenzmonitors beziehen. Referenzmonitore, welchen einen derartigen Zugriff auf Objekte durch Subjekte steuern, sind im Fachgebiet bekannt und können einen Sicherheitskern-Lösungsansatz nutzen.
Eine korrekte Implementation eines Referenzmonitors erfordert die Einhaltung von drei Prinzipien:
(1) Vollständigkeit, dahingehend, dass jeder Zugriff durch Subjekte auf Objekte oder andere Subjekte den Monitor mit einbeziehen muss;
(2) Isolation, dahingehend, dass der Monitor vor Eingriffen gesichert sein muss; und
(3) Verifizierbarkeit dahingehend, dass eine Übereinstimmung zwischen der Sicherheitsstrategie und der tatsächlichen Implementation des Monitors dargelegt werden muss.
Wie diskutiert sollte jede Bezugnahme auf Information oder Änderung einer Autorisierung durch den Referenzmonitor gehen. Somit werden alle von einem Benutzer oder einem anderen Objekt gegebenen Befehle von dem Referenzmonitor überwacht. Dieser Lösungsansatz ist insbesondere in Mehrfachbenutzer-Computerumgebungen nützlich.
Die Gesamtheit des Schutzmechanismus innerhalb eines Computersystems - einschließlich der Hardware, Software und Firmware deren Kombination für die Einhaltung der Sicherheitsstrategie verantwortlich ist - ist allgemein als eine "gesicherte Computerbasis" (TCB- trusted computing base) bekannt. Wenn die gesicherte Software aus Gründen der Verifizierung des Referenzmonitors so einfach wie möglich ausgelegt ist, ist dann die gesicherte Software als ein "Sicherheitskern" bekannt.
Im allgemeinen versuchen TCBs die in dem Orange Book beschriebenen Kontrollaufgaben zu erfüllen. Die Übereinstimmung mit diesen Aufgaben gibt dem Benutzer Vertrauen und vergrößert die Gesamterwünschtheit eines Computersystems. Diese Aufgaben befassen sich mit:
(1) Sicherheitsstrategie;
(2) Verantwortlichkeit; und
(3) Sicherheitsgefühl.
Das Ziel der Sicherheitsstrategie zieht eine Durchsetzung der gewünschten Sicherheitsregeln durch die TCB nach sich. Diese Sicherheitsregeln sind so ausgelegt, dass sie den Zugriff und die Verbreitung von Information in einer genau definierten Weise beschränken.
Sicherheitsstrategien können Vorkehrungen für die Durchsetzung sowohl von obligatorischen als auch wahlfreien Zugriffssteuerregeln umfassen. Obligatorische Zugriffssteuerregeln steuern den Zugriff direkt auf Vergleichen der Benutzersicherheitsstufe und der Empfindlichkeitsstufe der gesuchten Information. Wahlfrei Zugriffsregeln kontrollieren und begrenzen den Zugriff auf identifizierte Einzelpersonen, welche als einen Kenntnisbedarf habend festgelegt worden sind.
Die Zugangskontrollregeln erfordern, dass jedem Benutzeridentifikationscode eine die Zugriffsrechte des Benutzers anzeigende Erklärung zugeordnet ist. Dies Erklärung enthält oft Information, welche die Sicherheitsebene (für obligatorische und wahlfreie Kontrollzwecke)und die Mitgliedschaft in Gruppen (für wahlfreie Kontrollzwecke) darstellt.
Die Verantwortlichkeitsaufgabe erfordert, dass jedem Benutzer ein individueller Benutzeridentifikationscode (oft als "Benutzername" bezeichnet) gegeben wird, und dass die TCB in der Lage ist, den Code zu erkennen und sicherzustellen, dass er von seinem korrekten Benutzer verwendet wird. Dieses kann durch Überprüfen des Passwortes des Benutzer erfolgen. Diese Sicherstellung der Identität des Benutzers ist als "Authentisierung" bekannt.
Zusätzlich erfordert das Verantwortlichkeitserfordernis das Vorhandensein von Überprüfungsmöglichkeiten (Auditing). Solche Überprüfungsmöglichkeiten erlauben das Überprüfen von Aktionen, welche einen Zugriff auf die Erzeugung, oder die Freigabe klassifizierter oder empfindlicher Information bewirken können.

Sicherheitsaufgaben und "gesicherte" Systeme

Die Sicherheitsaufgabe ist insbesondere in dem vorliegenden Zusammenhang wichtig. Diese Aufgabe befasst sich mit der Unternehmung von Schritten, dass die Sicherheitspolitik korrekt implementiert wird und dass die TCB den Zweck dieser Strategie vermittelt und durchsetzt. Es können Schritte unternommen werden, dass jeder Abschnitt der TCB gesichert ist. Zur Erreichung dieses Ziel sind zwei Arten von Sicherheit erforderlich.
Die erste Art von Sicherheit ist die Lebensdauerzyklus- Sicherheit. Diese Art von Sicherheit bezieht sich auf Schritte, die unternommen werden, um sicherzustellen, dass das Computersystem mittels formalisierter und strenger Regelvorschriften entworfen, entwickelt und erhalten wird. Der zweite Typ von Sicherheit ist die Betriebssicherheit. Die Betriebssicherheit befasst sich mit den Merkmalen der verwendeten Systemarchitektur, um sicherzustellen, dass die Sicherheitsstrategie unumgehbar während des Systembetriebs durchgesetzt wird. Die gesamte Software (manchmal im Fachgebiet zwanglos als "Code" bezeichnet) in der TCB wird im allgemeinen analysiert, um die Sicherheitsstufe des Systems zu ermitteln.
Wenn der Codeumfang in der TCB zunimmt, wird es schwierig sicherzustellen, dass die TCB genau die Sicherheitsstrategie durchsetzt. Aus diesem Grunde ist es erwünscht, die Menge des gesicherten Codes und somit die Komplexität der TC8 zu minimieren.
Eine TCB wird üblicherweise in Verbindung mit einem erheblichem Softwareaufwand betrieben, wie z. B. Texteditoren oder anderen Anwendungen, welche innerhalb der Sicherheitsstrategie der TCB arbeiten, Im allgemeinen verlangt diese nicht gesicherte Software von der TCB einen Zugriff auf Objekte, wenn der Benutzer oder die nicht gesicherte Software diese benötigt. Somit wird die Mehrzahl der Benutzeranforderungen an die TCB, und die Mehrzahl der Information, die ein Benutzer von der TCB erhält durch die Vermittlung einer nicht gesicherten Software abgewickelt.
Diese nicht gesicherte Software ist jedoch von Natur her der Gefahr einer Beeinträchtigung ausgesetzt und fehleranfällig. Für einige Arten von Anforderungen und Anzeigen könnte ein böswillige oder fehlerhaft funktionierende ungesicherte Software die Durchsetzung der Sicherheitsstrategie beeinträchtigen. Im allgemeinen können die TCBs nicht zwischen Anforderungen unterscheiden, welche glaubwürdig von der nicht gesicherten Software auf Befehl eines Benutzers gemächt werden und entweder (1) Anforderungen, welche von der ungesicherten Software auf ihre eigene Initiative gemacht werden, oder (2) Anforderungen, welche den tatsächlichen Befehl des Benutzers falsch interpretieren. Beispielsweise wäre es möglich, wenn von einem autorisierten Benutzer gegebene Befehle zur Veränderung bestimmter Benutzersicherheitsstufen über die Vermittlung einer ungesicherten Software erfolgen, dass eine böswillige oder fehlerhaft funktionierende ungesicherte Software in unzulässiger Weise die Sicherheitsstufe eines Benutzers anhebt. Eine derartige unzulässige Anhebung einer Sicherheitsstufe könnte zu der Offenlegung empfindlicher Informationen führen.
Ferner können TCBs im allgemeinen nicht sicherstellen, dass von einer nicht gesicherten Software ausgeführte Anzeigen vertrauenswürdig sind. Dieses ergibt Probleme dahingehend, dass wenn Anzeigen oder Prüfungsaufzeichnungen unter Verwendung einer ungesicherten Software durchgeführt werden, es für eine böswillige ungesicherte Software möglich wäre, diese Prüfungsaufzeichnungen fehlerhaft darzustellen, um verdächtige Aktivitäten zu verbergen.
Zur Überwindung dieser Probleme haben Systeme nach dem Stand der Technik ein als "gesicherter Weg" bekanntes Konzept entwickelt. Ein gesicherter Weg ist ein Mechanismus, mittels welchem ein Benutzer direkt mit der TCB kommunizieren kann. Ein gesicherter Weg kann nur von dem Benutzer oder von der TCB aktiviert werden, und kann nicht durch ungesicherten Code imitiert werden. Ein derartiger gesicherter Weg ist eine sichere TCB/Benutzer-Verbindung, welche die gesamte, nicht gesicherte Software umgeht. Das Orange Book erfordert einen gesicherten Weg für alle Systeme, denen eine Sicherheitsstufe von B2 oder darüber gegeben wird.
Ein "gesicherter Befehl" (auch als ein Sicherheitswegbefehl bekannt) ist ein Befehl, welcher einen gesicherten Weg zwischen dem Benutzer für die TCB für die Ausführung erfordert. Die spezifische Sicherheitsstrategie eines Computersystems bestimmt, welche Befehle als gesicherte Befehle definiert sind. Beispielsweise wären Befehle, welche die Veränderung von Sicherheitsstufen von Benutzern betreffen, gesicherte Befehle.
Syntaxanalysatoren als Erhöher der Systemkomplexität Teilweise aufgrund festgestellter Ausführungsprobleme enthielten herkömmliche Computetsysteme oft Code zur Implementation bestimmter Funktionen in der TCB. Eine solche Funktion umfasst einen Codeabschnitt, welcher als der "Syntaxanalysator" (Parser) bekannt ist.
Der Syntaxanalysator führt die Grundinterpretation von Benutzerkommandos durch, indem er die für Menschen lesbare Darstellung eines Benutzerkommandos (z. B. eines von einem Benutzer in eine Tastatur eingegebenen Befehls) in eine von Maschinen lesbare Darstellung, bekannt als die binäre Darstellung oder den syntaxanalysierten Befehl umwandelt. Ein Benutzerbefehl kann aus einer von dem Benutzer eingetippten Gruppe von Worten bestehen, welche eine zu unternehmende Aktion spezifizieren. Der Benutzerbefehl kann auch eine oder mehrere Varianten oder Optionen dieser Aktion spezifizieren.
Zur Vereinfachung für den Benutzer, erlauben die meisten Syntaxanalysatoren die Eingabe dieser Optionsworte in einer beliebigen Reihenfolge ohne die Bedeutung des Benutzerbefehls zu verändern. Ferner erlauben es die meisten Syntaxanalysatoren dem Benutzer, die Worte entweder in einer vollständigen oder abgekürzten Form einzugeben. In einigen Fällen existieren mehrere mögliche Abkürzungen. Ferner kann bei den meisten Syntaxanalysatoren der Benutzer den Abstand zwischen den Worten ohne Veränderung der Bedeutung des Befehls verändern. Einige Syntaxanalysatoren prüfen auch die Benutzerbefehle auf korrekte Syntax, und melden dem Benutzer Fehler vor der Ausführung des Befehls. Andere Syntaxanalysatoren fragen den Benutzer nach fehlender Information, was die Notwendigkeit vermeidet einen unvollständigen Befehl komplett neu einzugeben.
Somit können mehrere unterschiedlich eingegebene für Menschen lesbare Repräsentationen jedem einzelnen eindeutigen syntaxanalysierten Befehl zugeordnet sein. Es ist die Aufgabe des Syntaxanalysators diese eingegebenen Repräsentationen des Benutzerbefehls (welche mit jedem Benutzer variieren können) genau in die spezifischen syntaxanalysierten Befehlsrepräsentationen zu übertragen. Aufgrund der komplexen Natur des Syntaxanalyse sind allgemeinen große Menge an Computercode dieser Aktivität zugeordnet. Herkömmliche gesicherte Softwaresysteme haben den Syntaxanalysator für gesicherte Befehle und somit den zugeordneten Code innerhalb der TCB enthalten. In diesen Systemen wurde jeder gesicherte Befehl exklusiv von dem gesicherten Code syntaxanalysiert und ausgeführt. Der Einschluss des Syntaxanalysecodes in der TCB wurde für einen korrekten Systemtrieb als erforderlich erachtet.
Wie vorstehend diskutiert, ist jedoch die Einfachheit und das Ausmaß der Sicherung eines Systems in etwa invers proportional zu der Komplexität der TCB des Systems. Somit führt der Einschluss des Syntaxanalysators in der TCB in einer komplexeren Sicherheitsanalyse und einer entsprechenden Verringerung des Vertrauens in das System. Herkömmliche Vorrichtungen haben (da sie zur Unterstützung der Sicherheit klein und einfach sein mussten) inhärent die Benutzerfreundlichkeit von Computersystemen eingeschränkt.
Die vorliegende Erfindung stellt eine Anzahl von Vorteilen gegenüber dem Stand der Technik bereit. Durch eine Reduzierung der Komplexität der TCB wird die Menge des gesicherten Codes, der verifiziert oder gesichert werden muss, verringert. Zusätzlich wird die allgemeine Verwendbarkeit des Systems erhöht, da ein verbessertes Verfahren zur Verarbeitung gesicherter Befehle die Implementation zusätzlicher Berechnungsfunktionen mit geringen oder keinen zusätzlichen Kosten in der TCB-Sicherung ermöglicht.
Die vorliegende Erfindung umfasst ein verbessertes Verfahren für die Ausführung gesicherter Befehle gemäß Anspruch 1. In diesem verbesserten Verfahren werden die erforderlichen Schritte für die Durchführung eines gesicherten Befehls zwischen einen gesicherten und einem nicht gesicherten Code aufgeteilt. Auf diese Weise kann die Menge an gesicherten Code in der TCB signifikant reduziert werden. Die vorliegende Erfindung stellt ferner ein Computerprogrammprodukt gemäß dem Anspruch 12 und eine Computervorrichtung gemäß dem Anspruch 13 bereit.
Wie vorstehend diskutiert, kann die Syntaxanalyse eines Befehls vergleichsweise schwierig sein und erfordert oft große Mengen an komplexen Code. Es ist jedoch relativ einfach, die syntaxanalysierte Repräsentation eines Befehls in eine standardmäßige für Menschen lesbare Repräsentation zur Anzeige für den Benutzer zu übersetzten. Dieses beruht zum Teil darauf, dass nur eine standardmäßige für Menschen lesbare Repräsentation jeder syntaxanalysierten Repräsentation zugeordnet sein kann. Die vorliegende Erfindung nutzt diese Tatsache, indem sie gesicherte Befehle im ungesicherten Code vor einer Ausführung in der TCB syntaxanalysiert.
Im allgemeinen beinhaltet die vorliegende Erfindung ein Computersystem, welches eine als ein Referenzmonitor arbeitende TCB enthält. In der TCB ist der sicherheitsrelevante Code enthalten, welcher für die tatsächliche Ausführung des gesicherten Befehls erforderlich ist.
Der TCB sind ein oder mehrere nicht gesicherte Subjekte (z. B. Prozesse) zugeordnet. Jedes derartige Subjekt besitzt spezielle Zugriffsrechte, welche eine Sicherheitsstufe beinhalten können. Diese nicht gesicherten Subjekte kommunizieren nur unter Einbeziehung der TCB. Die TCB erlaubt nur eine von der Systemsicherheitsstrategie zugelassene Kommunikation. Jedes nicht gesicherte Subjekt ist im wesentlichen unabhängig.
In jedem dieser nicht gesicherten Subjekte wird im allgemeinen ungesicherte Software ausgeführt. Diese ungesicherte Software kann ein ungesichertes Betriebssystem (UOS) enthalten, und enthält im allgemeinen Anwendungen, wie z. B. Texteditoren. In der vorliegenden Erfindung enthält der ungesicherte Code die nicht sicherheitsrelevanten Funktionen, welche für die Ausführung eines gesicherten Befehls erforderlich sind.
An dem Computersystem sind mehrere Benutzerterminals angeschlossen. Die Benutzerterminals ermöglichen es dem Benutzer, Information mit dem Computersystem auszutauschen. Die gesamte Terminalaktivität wird zuerst von der TCB gesehen. Eine Sicherheitstaste ist speziell für die Verwendung auf jedem an dem Computersystem angeschlossenen Terminal vorgesehen. Die TCB ist dafür ausgelegt, dieses Tastensignal zu erkennen und zu erfassen. Die Aktivierung dieser Taste durch den Benutzer baut einen gesicherten Weg zwischen dem Benutzerterminal und der TCB auf. Alternative Verfahren für den Aufbau eines gesicherten Weges können ebenfalls verwendet werden.
Die TCB ist im allgemeinen mit einer begrenzten Anzahl von "direkten" Benutzerbefehlen (Direktbefehlen) ausgestattet.
Deshalb findet der Großteil der Benutzeraktivitäten in dem ungesicherten Betriebssystem statt.
Während des Betriebs in dem UOS kann der Benutzer versuchen, einen gesicherten Befehl auszuführen. Wenn einer dieser Befehle von dem Benutzer gegeben wird, prüft der ungesicherte Code in dem UOS die Syntax des Befehls und kann fehlende Parameter melden; dann wandelt der ungesicherte Syntaxanalysator den Befehl in einer syntaxanalysierte Repräsentation um, welche hier zur Vereinfachung als die "binäre Repräsentation" bezeichnet wird. In einigen Fällen werden Befehlsprozeduren und von der Anwendung gegebene gesicherte Befehle ebenfalls syntaxanalysiert und in eine binäre Repräsentation übersetzt.
Diese binäre Repräsentation wird dann von dem UOS an die TCB weitergegeben. Die TCB ordnet am Anfang die binäre Repräsentation einem physischem Terminal zu und kopiert die binäre Repräsentation in einen diesem Terminal zugeordneten Speicherpuffer.
Sobald dieses abgeschlossen ist, kann der nicht gesicherte Code in dem UOS den Benutzer zur Aktivierung der Sicherheitstaste auffordern. Wenn diese Taste aktiviert wird, wird ein gesicherter Weg zwischen dem Benutzerterminal und der TCB aufgebaut. Alternative Verfahren können ebenfalls zur Initialisierung dieses gesicherten Weges angewendet werden. Eine zufällig erzeugte Prozess-ID, welche beim Einloggen erzeugt werden kann, kann dazu genutzt werden, um zu verhindern, dass ungesicherter Code einen gesicherten Weg simuliert.
Eine anschließende Aktivität der TCB hängt von der Art des Befehls ab, welcher durch dir binäre Repräsentation wird. Wenn der Befehl einer ist, welcher keinerlei Information verändert, dass heißt eine Anforderung für die Betrachtung von Information, verifiziert die TCB, dass der Benutzer alle erforderlichen Zugriffsrechte besitzt und versucht die binäre Repräsentation auszuführen. Eine für Menschen lesbare Standardrepräsentation des von der TCB empfangenen binären Befehls wird zusammen mit der Information angezeigt.
In den meisten Fällen, wenn der von dem Benutzer angeforderte Befehl eine Modifikation von Information erfordert, zeigt die TCB zur Bestätigung eine standardmäßige für Menschen lesbare Form des Befehls zusammen mit einer Anzeige an, was das Ergebnis der Befehlsausführung sein wird. Der Benutzer wird dann aufgefordert, zu bestätigen (indem er eine Antwort über dem gesicherten Weg eingibt), dass der dargestellte Befehl korrekt empfangen wurde und ausgeführt werden sollte.
Diese Bestätigung ermöglicht es dem Benutzer sicherzustellen, dass ungesicherter Code keine nicht autorisierte Modifikation des ursprünglichen Befehls des Benutzer durchgeführt hat. Ferner ermöglicht die Bestätigung die Detektion aller Fehler, welche während des Syntaxanalyseprozesses aufgetreten sein können, durch den Benutzer. In Situationen, in welcher die binäre Repräsentation eine Befehlsprozedur oder einen von einer Anwendung gegebenen Befehl repräsentiert, stellt die Bestätigung sicher, dass der von der nicht gesicherten Software vorgeschlagene Befehl für den Benutzer akzeptabel ist.
Wenn der Befehl von dem Benutzer bestätigt ist, führt die TCB eine Prüfung aus, um sicherzustellen, dass der Benutzer die notwendigen Zugriffsrechte für die Ausführung des Befehls besitzt, und versucht, wenn dies der Fall ist, den Befehl auszuführen.
Ein besonderer Vorteil der vorliegenden Erfindung ergibt sich aus der Tatsache, dass die Ausführung eines gesicherten Befehls zwischen einem gesicherten Code und einem ungesicherten Code aufgeteilt wird. Die tatsächliche Syntaxanalyse des Befehls erfolgt in einem ungesicherten Code. Der in der TCB enthaltene gesicherte Code prüft die syntaxanalysierten Befehle auf Korrektheit und zeigt sie dem Benutzer in einer für Menschen lesbaren Form an. Dieses Prüfen und Anzeigen eines syntaxanalysierten Befehls erfordert erheblich weniger Code als für die Syntaxanalyse eines Befehls erforderlich ist.
Somit wird, da der Befehlssyntaxanalysator in dem ungesicherten Code enthalten ist, die Menge des gesicherten Codes in der TCB minimiert. Dieses verringert die Schwierigkeit einer gesicherten Systemzuverlässigkeit und erhöht das Vertrauen, das in das System gesetzt werden kann.
Es ist ein weiterer Vorteil dieser Erfindung, dass die Benutzerschnittstelle von den durch die TCB durchgeführten zugrundeliegenden Funktionen getrennt ist. Dieses erlaubt die Implementation von alternativen UOS/Benutzer-Schnittstellen ohne größere Modifikationen der TCB. Ferner wird der Zeitbedarf und Aufwand zur Entwicklung einer derartigen Befehlsschnittstelle verringert. Noch ein weiterer Vorteil besteht darin, dass mehr Nutzungsmerkmale vorgesehen werden können, ohne die Komplexität der TCB erheblich zu vergrößern. Beispiele derartiger Nutzbarkeitsmerkmale sind Befehlszeileneditierung und Wiederholung.
Fig. 1: veranschaulicht die verschiedenen Stufen innerhalb eines Computersystems;
Fig. 2: veranschaulicht verschiedene Schichten innerhalb der gesicherten Rechnerumgebung;
Fig. 3: veranschaulicht einen gesicherten Weg;
Fig. 4A und 4B: sind Flussdiagramme, welche ein Verfahren zur Durchführung gesicherter Befehle darstellen. Unterschiede in der Kästchendarstellung in diesen Zeichnungen werden nachstehend erläutert;
Fig. 5: veranschaulicht ein Verfahren zur Implementierung der Erfindung;
Fig. 6: ist ein Flussdiagramm, welches ein Verfahren zur Verifizierung eines gesicherten Weges darstellt;
Fig. 7: ist ein Zustandsübergangsdiagramm einer weiteren Ausführungsform, welche verschiedene Befehlszustände nutzt.
Eine spezifische Ausführungsform der vorliegenden Erfindung wird unter Bezugnahme auf ein Computersystem beschrieben, welches verschiedene Anwenderprozesse unterstützt und in einer Mehrfachnutzungsumgebung arbeiten kann. Zur Veranschaulichung wird eine Implementation in Verbindung mit einem Computer Modell VAX, erhältlich von Digital Equipment Corporation (DEC) kurz beschrieben. Es dürfte sich verstehen, dass die vorliegende Erfindung ohne weiteres auf verschiedene Arten von Computersystemen, einschließlich PC-Netzen, alleinstehende Mehrfachbenutzercomputersysteme oder Einzelbenutzercomputersysteme angewendet werden kann, um nur einige Beispiele zu benennen.

Übersicht über die Softwarearchitektur

Fig. 1 stellt eine bevorzugte Computerumgebung dar, welche insgesamt durch das Bezugszeichen 2 bezeichnet ist. Eine gesicherte Computerbasis (TCB) 10 liegt in dem Mittelpunkt des Computerssystems. Die TCB 10 wirkt als ein Referenzmonitor dahingehend, dass ein Zugriff auf Information durch die TCB 10 vermittelt wird.
In einer allgemeinen Ausführungsform der Erfindung kann die TCB 10 ein sicherer Kern sein, welcher unter dem allgemeinen Betriebssystem eines Computersystems liegt. In einer Ausführungsform weist die TCB 10 gesicherten Code auf, der unterhalb einem VMS- oder Ultrix-System (dem UOS) liegt.
Die TCB 10 setzt eine Sicherheitsstrategie durch, welche zulässige Zugriffsmodi zwischen Benutzern oder Computerprozessen (Subjekten) und Dateien, Speichersegmenten oder anderen Objekten identifiziert. Der Zugriff auf die gespeicherte Information wird von der TCB 10 vermittelt, so dass die TCB 10 bestimmen kann, ob ein spezieller Benutzer oder ein nicht gesichertes Subjekt auf eine spezielle Information zugreifen kann. Damit die TCB 10 ihre Schutzfunktion erfüllen kann, muss sie die drei vorstehend diskutierten Anforderungen: (1) Vollständigkeit, (2) Isolatian und (3) Verifizierbarkeit berücksichtigen.
Ein vollständigeres Verständnis der TCB 10 kann durch Bezugnahme auf Fig. 2 erhalten werden. Wie es dargestellt ist, kann die TCB 10 mehrere unterschiedliche Schichten aufweisen. Jede Schicht der TCB weist gesicherten Code auf. Dieser gesicherte Zustand, wird durch eine Sicherheitsgrenze 11 dargestellt. In einer Ausführungsform sind Schichten von besonderem Interesse, die als: sicherer Server (SSVR) 12, Befehlsübertragungseinrichtung (CC) 14 und virtuelle Terminals (VT) 16 zu bezeichnen sind.
Die TCB 10 enthält den gesicherten Code, der zur Sicherstellung der Übereinstimmung mit den Anforderungen des Orange Book erforderlich ist. In alternativen Ausführungsformen kann der gesicherte Code die Übereinstimmung mit unterschiedlichen Systemen von Sicherheitsanforderungen übereinstimmen. Die TCB 10 enthält auch den Code, welcher tatsächlich den angeforderten gesicherten Befehl ausführt, wie es nachstehend diskutiert wird.
Jedes ungesicherte Subjekt wird im allgemeinen von einem ungesicherten Prozess unterstützt. Dieser Prozess kann Zeit in einem von zwei "Modi" verbrauchen. Der erste Modus, in welchem der Prozess üblicherweise abläuft, ist als der "Benutzermodus" bekannt. Dieser Modus ist ein eingeschränkter Hardwarezustand, wie z. B. der VAX-Benutzermodus, der im Fachgebiet bekannt ist.
Dieser Prozess kann auch Zeit bei der Ausführung von gesicherten Code in einem alles leistenden Hardwarezustand verbrauchen. Dieser Zustand wird durch den VAX-"Kernelmodus" repräsentiert, welcher im Fachgebiet bekannt ist.
Dieser Zustand kann durch das ungesicherte Subjekt über eine Anforderung des Sicherheitskerns ausgelöst werden. Eine solche Anforderung kann in herkömmlicher Weise folgen und wird üblicherweise als "Kernaufruf" bezeichnet. Dieser Modus kann auch durch asynchrone Ereignisse (z. B. den Abschluss einer zuvor von dem ungesicherten Subjekt durchgeführten Eingabe/Ausgabe-Anforderung) ausgelöst werden. In einer Ausführungsform hat die TCB 10 auch einen Prozess jedem Terminal zugeordnet, welcher mit dem Benutzer über den gesicherten Weg kommuniziert. Dieser Prozess ist in dem Fachgebiet als ein "Ausführungsfaden" bekannt. In dieser Ausführungsform teilt jeder Ausführungsfaden einen Adressenraum mit anderen TCB-Anführungsfäden. Ein Vorteil einer derartigen Aufteilung ist die Ökonomie von Maschinenressourcen. Voll aufgeblasene Prozesse, jeder mit seinem eigenen Adressenraum würden weitaus mehr Maschinenressourcen erfordern, als wenn eine derartige Adressenraumteilung angewendet wird.
Es ist die CC 14, welcher die Kommunikation zwischen den Prozessen für die Übergabe syntaxanalysierter Befehle zwischen den Prozessen, welche ungesicherte Subjekte unterstützen und den Prozessen innerhalb der TCB 10 die den gesicherten Weg unterstützt, bereitstellt.
Der ungesicherte Code kann der TCB 10 die syntaxanalysierte Repräsentation des gesicherten Befehls weitergeben, indem er einen Kernaufruf tätigt. Der Kernaufruf bewirkt, dass der das ungesicherte Subjekt unterstützende Prozess in den alles leisteten Hardwarezustand umgeschaltet wird und mit der Ausführung von gesicherten Code beginnt, der für die Handhabung von Kernaufrufen ausgelegt ist. Dieser gesicherte Code erkennt die Art des Kernaufrufes und ruft die CC 14 auf. Die CC 14 erhält kopiert dann die binäre Repräsentation des gesicherten Befehls in einen geschützten Speicher und legt sie in einer globalen Datenstruktur ab, welche den dem fraglichen Terminal zugeordneten Prozess unterstützt.
Die VT 16 Schicht enthält den gesicherten Code, welche die gesamte Terminalaktivität überwacht und die Aktivierung der Sicherheitstaste prüft. In einer speziellen Ausführungsform kann die VT 16 Schicht auch Code enthalten, welche verfolgt, welches physische Terminal einem speziellen Benutzer oder einem ungesicherten Subjekt zugeordnet ist.
Die spezifische Art der Implementation der vorstehenden beschriebenen Aktivitäten wird für den Fachmann auf diesem Gebiet mit dem Vorteil dieser Offenbarung offensichtlich sein.
Gemäß Fig. 1 und 3 liegt "um" die TCB 10 "herum" ein im allgemeinen nicht gesichertes Betriebssystem (UOS) 20. Das UOS 20 weist im allgemeinen ungesicherten Code auf, und kann ein herkömmliches Betriebssystem, wie z. B. Ultrix oder VMS enthalten. Alternative Aufbauformen sind vorstellbar, in welchem das UOS 20 einen beliebigen, nicht gesicherten Code enthält. Man wird klar erkennen, dass das System nicht gesicherten Code enthalten kann, der von der TCB 10 und dem UOS 20 getrennt ist.
Der Großteil der Benutzeraktivität wird in dem UOS 20 erfolgen. In einer Ausführungsform kann ein spezifisches UOS 20 in jedem ungesicherten Subjekt ablaufen.

Benutzerterminals und die Sicherheitstaste

Dem Computersystem sind eines oder mehrere Terminals 30 zugeordnet. Diese Terminals 30 können einen herkömmlichen Aufbau dahingehend aufweisen, dass sie dem Benutzer den Austausch von Information mit dem Computersystem ermöglichen. Es können entweder "intelligente" oder "dumme" Terminals verwendet werden. Beispiele solcher dummen Terminals sind die allgemein bekannten Terminals der HT-Serie 200 und 300. Dieses Terminals sind von Digital Equipment Corporation oder deren autorisierten Händlern erhältlich. Ein besonders nützliches Terminal enthält eine Steuerungsprogrammierung, welche unter Berücksichtigung von Sicherheitsmerkmalen ausgelegt ist, wie es beispielsweise in EP- 043636 unter dem Titel "Method for Securing Terminal and Terminal Apparatus for Use with the Method", von Wei-Ming Hu, Clifford E. Kahn, Andrew H. Mason und Peter A. Sichel beschrieben ist.
Eine Tastatur ist an jedes Benutzerterminal angeschlossen. Jede Tastatur enthält eine als Sicherheitstaste verwendete Taste. Diese Taste wird zum Aufbau eines gesicherten Weges zwischen dem Benutzerterminal und der TCB 10 Verwendet. In einer Ausführungsform ist die Sicherheitstaste eine "Außerband-Taste" für das UOS 20. Es ist erwünscht, dass das von dem Terminal bei der Aktivierung der Sicherheitstaste gesendete Signal im allgemeinen nicht von in dem UOS 20 laufenden Anwendungen verwendet wird. Eine Außerband- Taste ist günstig, da sie nicht die herkömmliche Anzahl von Benutzertasten einschränkt, und das Signal selbst dann sofort gesendet wird, wenn ein anderer E/A-Vorgang anhängig ist. Beispielsweise kann die Taste BREAK auf der Terminaltastatur die Sicherheitstaste sein.
In vielen Terminals (wie z. B. denen der VT 2XX und VT 3XX Familien) verhindert die Verriegelung der Tastatur die Weitergabe mehrerer Tastensignale. In diesen Terminals kann jedoch das Signal der BREAK-Taste selbst von einer verriegelten Tastatur aus übertragen werden. Dies ist im allgemeinen erwünscht, um die BREAK-Taste als die Sicherheitstaste zu verwenden. Ferner kommt das durch die Aktivierung der BREAK-Taste erzeugte Signal vor den anderen Zeichen in dem Tastaturpuffer. Ein weiterer Vorteil der Verwendung der BREAK-Taste besteht darin, dass die in dem UOS 20 laufende Software bestimmte Terminals nicht dazu bringen kann, ein Zeichen zu senden.

Der gesicherte Weg und direkte Befehle

Die TCB 10 arbeitet im allgemeinen als ein Referenzmonitor.
Nach dem anfänglichen Einloggen oder zu anderen Zeitpunkten, wenn der Benutzer nicht mit einem Prozess in dem UOS 20 (z. B. einem Anwendungsprogramm) verbunden ist, reagiert die TCB 10 auf eine vergleichsweise eingeschränkte Reihe "direkter Befehle", welche einen CONNECT-Befehl zum Verbinden mit einem ungesicherten Subjekt enthalten. Wenn der Benutzer mit einem solchen ungesicherten Subjekt verbunden ist, prüft die TCB 10 das Sicherheitssignal; wenn ein anderes Signals als das Sicherheitssignal empfangen wird, leitet die TCB 10 das Signal zu dem verbundenen ungesicherten Subjekt weiter.
Wie vorstehend diskutiert, überwacht in einer spezifischen Ausführungsform der gesicherte Code in der VT Schicht 16 die gesamte Terminalaktivität. Wenn der Code in der VT 16 erkennt, dass die BREAK-Taste gedrückt wurde, wird dem SSVR dieses in einer herkömmlichen Weise (wie z. B. durch Weiterzählen eines Ereigniszählers oder Aktivierung eines Flags) signalisiert. Der Code in der SSVR 12 erkennt diese Signalisierung und baut einen gesicherten Weg zwischen dem Benutzerterminal und sich selbst auf. Auf diese Weise wird das Sicherheitstastensignal durch die TCB 10 erfasst.
In bestimmten Sicherheitsumgebungen erfordern allgemeine Sicherheitsanforderungen, dass die TCB 10 Anzeigen erstellt, wenn ein gesicherter Weg aufgebaut und von dem Benutzer verlassen wird. In einer Ausführungsform sendet die TCB, wenn ein gesicherter Weg aufgebaut wird, eine Rücksetzbefehlsfolge an das physische Benutzerterminal 30, um sicherzustellen, dass es sich in einem bekannten Zustand befindet. Dieses erfolgt teilweise deshalb, um sicherzustellen, dass die dem Benutzer durch die TCB 10 dargestellte Information in der gewünschten Form (z. B. in dem korrekten Zeichensatz) vorliegt. Eine besonders sinnvolle Folge von Befehlen zur Implementierung der Rücksetzbefehlsfolge ist in der vorstehend erwähnten, gleichzeitig anhängigen U. S. Patentanmeldung von Hu et al. beschrieben.
Wenn die Sicherheitstaste anders als in Verbindung mit der Ausgabe eines gesicherten Befehls aktiviert wird, zeigt der Sicherheitsserver 12 eine spezielle Schlagzeile und Meldung (z. B.: "SSVR > ") zusammen mit dem nachstehend diskutierten Prozessidentifikator des Benutzers, um anzuzeigen, dass der Benutzer interaktiv mit gesichertem Code kommuniziert. Wenn die Sicherheitstaste in Verbindung mit der Ausgabe eines gesicherten Befehls aktiviert wird, zeigt der Sicherheitsserver 12 dem Benutzer eine bestimmte Anzeige an, was ausgeführt werden soll, wie es nachstehend diskutiert wird.
Wenn eine Befehlsausführung abgeschlossen ist, oder wenn der Benutzer eine Sitzung mit dem UOS 20 aufbaut oder reaktiviert, gibt die TCB 10 eine Meldung aus, die den Benutzer informiert, dass er/sie den gesicherten Weg unterbricht. Wenn eine Sitzung mit der TCB abgeschlossen ist, kann der Speicher in dem physischen Terminal durch die TCB gelöscht werden. Dieses erfolgt, um gesicherte Information sowohl vor ungesicherten Code und nicht klassifizierten Personen zu schützen, welche das Terminal später benutzen. Ein besonders vorteilhaftes Verfahren zur Löschung des Terminalspeichers ist in der vorstehend erwähnten, gleichzeitig anhängigen Patentanmeldung beschrieben.
Die Anzahl von direkten Benutzerbefehlen, welcher aus der TCB 10 zur Verfügung stehen, ist bevorzugt eingeschränkt um die Komplexität der TCB 10 zu reduzieren. Im allgemeinen ist ein Befehl direkt, wenn:
a, man den Befehl benötigt, wenn man nicht mit einem ungesicherten Subjekt verbunden ist;
b. Endbenutzer von dem korrekten Verhalten des Befehls für die Sicherheit (z. B. LOGOUT) abhängen; oder
c. der Befehl ausgegeben werden muss, wenn kein Benutzerprozess in dem UOS 20 abläuft.
In den meisten Fällen kommuniziert der Benutzer mit der TCB 10 über den SSVR 12. In einer Ausführungsform kann der mit dem SSVR 12 kommunizierende Benutzer auf Befehle beschränkt sein, welche ihm/ihr einen Aufbau (Verbindung) oder Beendigung (Unterbrechung) einer Computersitzung in dem allgemeinen UOS 20 erlauben. Weitere Befehle können hinzugefügt sein, wie z. B. eine Erlaubnis für den Benutzer, die existierenden UOS 20. Sitzungen zu betrachten oder sein, bzw. ihr Passwort zu verändern, wobei es aber im allgemeinen erwünscht ist, die Anzahl der verfügbaren Befehle in der TCB 10 zu beschränken. Es ist ferner erwünscht, eine Einfachheit in der Syntax dieser direkten Befehle sicherzustellen.
Die einfache Syntax der direkten Befehle und die vergleichsweisen geringen Codemengen, die zur Interpretierung dieser Befehle erforderlich sind, erhöhen die Komplexität der TCB 10 nicht wesentlich.

Verarbeitung des Einlog-Vorgangs durch die TCB

Zur Initialisierung einer Computersitzung in dem Beispiel- UOS 20 kann sich der Benutzer zuerst in die Computerumgebung durch den SSVR 12 einloggen. Um den Einlog-Vorgang auszulösen, aktiviert der Benutzer die Sicherheitstaste (oder führt irgend eine andere Aktion durch, um die Aufmerksamkeit des SSVR 12 zu erhalten). Wie vorstehend beschrieben, baut dieses einen gesicherten Weg zwischen dem Benutzerterminal und der TCB 10 auf. Weitere Ausführungsformen sind vorstellbar, wobei andere Verfahren zum Aufbau eines gesicherten Weges verwendet werden.
Sobald ein gesicherter Weg aufgebaut wurde, zeigt der SSVR 12 dem Benutzer seinen/ihren spezifischen Benutzernamen und das Passwort an. Die verschiedenen Schichten in der TCB 10 führen allgemein bekannte Sicherheitsprüfungen durch, um sicherzustellen, dass der Benutzer die notwendigen Zugriffsrechte besitzt, um sich an dem Terminal einzuloggen. Wenn der Benutzer die erforderlichen Zugriffsrechte besitzt, wird eine Computersitzung in dem SSVR 12 aufgebaut.
Zu diesem Zeitpunkt wird die Sicherheitsinformation des Benutzers durch die TCB 10 gespeichert. Die TCB 10 speichert in dem Speicher auch einen eindeutigen Identifikator des Benutzerprozesses. Diese Information wird von der TCB 10 in dem Speicher gehalten, bis sich der Benutzer aus dem TCB 10 ausloggt.

Verbindung zu einem nicht gesicherten Prozess

Da die Anzahl direkter Benutzerbefehle in der TCB bevorzugt beschränkt ist, wird es der Benutzer im allgemeinen bevorzugen, eine Rechnersitzung mit einem nicht gesicherten Subjekt aufzubauen. Ein solches nicht gesichertes Subjekt kann in dem UOS 20 vorhandene Anwendungsprogramme beinhalten.
In einer spezifischen Ausführungsform wird, wenn der Benutzer eine Computersitzung in dem UOS 20 aufbaut, das physische Terminal 30 des Benutzer einem virtuellem Terminal des UOS zugeordnet. Der Benutzer kommuniziert mit dem nicht gesicherten Subjekt über eine Computersitzung innerhalb des UOS 20. Wenn eine solche Verbindung mit einem ungesicherten Subjekt aufgebaut ist, speichert die VT Schicht 16 der TCB 10 im Speicher, welches physische Terminal 30 welchem virtuellen Terminal in einem nicht gesicherten Subjekt zugeordnet ist. Auf diese Weise können von einem ungesicherten Subjekt empfangene gesicherte Befehle dem tatsächlichen Benutzer bei dem physischen Terminal 30 zugeordnet werden. Sobald der Benutzer einen Computersitzung innerhalb des UOS 20 aufgebaut hat, können normale Computeraktivitäten ausgeführt werden.
Ein detaillierteres Verständnis dieser Aktivitäten kann durch Bezugnahme auf Fig. 4A und 4B erhalten werden. Aktivitäten, welche durch dick umrandete Blöcke angezeigt werden, werden durch die TCB 10 oder gesicherten Code ausgeführt. Aktivitäten, welche durch dünn umrandete Blöcke dargestellt sind, werden von nicht gesicherten Code ausgeführt.
In Fig. 4A ist das Benutzerterminal mit einer innerhalb der allgemeinen UOS 20 aufgebauten Computersitzung 100 dargestellt. Während der Sitzung kann der Benutzer versuchen, verschiedene Befehle auszuführen. Hilfsprogramme innerhalb des UOS 20 ermitteln, ob die ausgegebenen Befehle gesicherte Befehle 50 sind, Wenn der Befehl durch das UOS 20 nicht als gesicherter Befehl identifiziert wird, versucht das UOS 20 den Befehl bei dem Prozess 60 auszuführen. In diesen Fällen kann der Betrieb und die Existenz der TCB 10 einen kleinen Einfluss auf das Verhalten des Befehls aus der Sicht des Benutzers aufweisen.

Der Prozessidentifikator

In einer Ausführungsform wird ein Prozessidentifikator (Prozess-ID) jedem Benutzerprozess zum Zeitpunkt des Einlog-Vorgangs zugeordnet. Dieser Prozess-ID ist eine pseudozufällig erzeuge alphanumerische Kennung, welche dem Benutzer während seines/ihrer Computersitzung zugeordnet wird.
Der Prozess-ID ist nützlich, wenn der ungesicherte Code zeitweise die Auswirkung der Aktivierung der Sicherheitstaste deaktivieren oder verzögern kann. Beispielsweise kann ein ungesicherter Code einen Rücksetzbefehl an einige Terminals senden. Während diese Terminals zurückgesetzt werden, hat die Aktivierung der Sicherheitstaste keine Auswirkung. Ein solches Verfahren kann ermöglichen, dass ungesicherter Code dem Benutzer zum dem Denken verleitet, dass ein gesicherter Weg aufgebaut wurde, obwohl er nicht aufgebaut wurde. Der Prozess-ID verhindert derartige Tricks, indem er dem Benutzer eine Unterscheidung zwischen tatsächlichen und emulierten gesicherten Wegen ermöglicht.
Wenn sich der Benutzer zum erstenmal einloggt, kennt er/sie noch nicht den Prozess-ID und kann keinen falschen ungesicherten Weg detektieren. Um jedoch einen Einlog- Dialog zu simulieren, müsste der ungesicherte Code erraten, wann der Benutzer die Sicherheitstaste betätigte, oder irgendwie die Aktivierung der Taste detektieren, obwohl sie die TCB nicht detektieren konnte. Ein Erraten der Aktivierungszeit ist unmöglich, da Benutzer ihre Einlog-Dialoge nach ihrem eigenen Gutdünken starten und der TCB kein Signal im voraus über die Aktivierung der Sicherheitstaste geben. Ein Detektieren der Sicherheitstaste, obwohl sie durch die TCB nicht detektiert werden konnte, wäre nur möglich, indem man die Taste veranlasst, ein anderes Signal auszugeben als die TCB erwartet. Verfahren um ein solches Ereignis zu verhindern, sind in der gleichzeitig anhängigen vorstehend erwähnten Anmeldung von Hu et al. beschrieben.
Bei einigen Terminals kann der ungesicherte Code in der Lage sein, das Terminal so zu programmieren, dass die Sicherheitstaste ein Signal erzeugt, das für den ungesicherten Code erkennbar ist, aber nicht für die TCB. In diesen Fällen wäre die Erzeugung der Prozess-ID zum Zeitpunkt des Einlog-Vorgangs unzureichend. Stattdessen kann der Prozess-ID vor dem Einloggen des Benutzers erzeugt werden. Beispielsweise kann in diesen Ausführungsformen der Prozess-ID erzeugt werden, wenn der Benutzer in der TCB 10 registriert und in dem geschützten Speicher gespeichert wird. In dieser Ausführungsform kann dem Benutzer eine Möglichkeit, seinen/ihren Prozess-ID zu verändern gegeben werden, so als ob der Benutzer generell sein/ihr Passwort verändern könnte.
In einer speziellen Ausführungsform erzeugt der SSVR 12 wenn sich der Benutzer einloggt einen Prozess-ID und weist diesen ID dem spezifischen Benutzer an dem physischen Terminal zu. Verfahren zum Erzeugen pseudozufälliger Identifikatoren sind im Fachgebiet allgemein bekannt. In einer Ausführungsform basiert der Pseudozufallsausgangspunkt auf einem Hardware-(im Gegensatz zu einem Software)-Ereignis. Der Algorithmus zur Erzeugung sukzessiver Zufallszahlen sollte rechnerisch schwierig zu invertieren sein.
Dieser Prozess-ID wird innerhalb der TCB aufbewahrt und niemals an den ungesicherten Code geliefert. Somit wird verhindert, dass ungesicherter Code in dem allgemeinen UOS 20 den dem Benutzer zugeordneten spezifischen Prozess-ID aufdeckt.
Der Benutzer ist für die Notierung und Aufbewahrung seines/ihres zugeordneten Prozess-IDs verantwortlich. Um das Merken durch den Benutzer zu fördern, kann der Prozess-ID als eine aussprechbare Gruppe von Zeichen erzeugt werden. Verfahren für die Erzeugung derartiger aussprechbarer Passwörter sind in "A Random Word Generator", MITRE Technical report (MTR-3006), Mai, 1975, von Morrie Gasser beschrieben.
Der Prozess-Identifikator wird dem Benutzer angezeigt, wenn ein gesicherter Weg zwischen dem Benutzerterminal und dem SSVR 12 aufgebaut ist. Die Anzeige des ID dient einer nützlichen Sicherheitsfunktion, da sie verhindert, dass ungesicherter Code dem Benutzer "täuscht". Bei fehlendem Prozess-ID kann es für ein ungesichertes Subjekt möglich sein den SSVR 12 zu emulieren. Ein den SSVR 12 emulierendes Subjekt, kann in der Lage sein, dem Benutzer sicherheitsrelevante Information zu entlocken, oder anderweitig die Systemsicherheit beeinträchtigen.
Der nur dem Benutzer und dem SSVR 12 bekannte Prozess-ID verhindert diese Art von "Täuschung". Bevor der Benutzer auf eine offensichtliche Anforderung des SSVR 12 antwortet, kann er/sie zuerst verifizieren, dass der korrekte Prozess-ID angezeigt wird. Da der Prozess-ID nur dem Benutzer und dem SSVR 12 bekannt ist, ist es für ein ungesichertes Subjekt, das den Prozess-ID nicht kennt, extrem schwierig, den Benutzer glauben zu lassen, dass er/sie mit dem SSVR 12 kommuniziert.
Fig. 6 veranschaulicht ein Flussdiagramm dieses Prozesses. Wenn sich der Benutzer zu Beginn in das Computersystem über den SSVR 12 einloggt, wird dem Benutzer ein zufällig erzeugter Prozess-ID zugeordnet. Diese Aktivität wird durch den Prozess 310 dargestellt. In einer Ausführungsform weist dieser Prozess-ID alphabetische Zeichen auf, und ist aussprechbar. Die aussprechbare Art fördert das Merken des ID durch den Benutzer. Der Prozess-ID wird dann durch den SSVR 12 im gesicherten Speicher gespeichert und dem Benutzer durch den SSVR 12 bei dem Prozess 320 angezeigt.
Während des Verlaufs der Computersitzung ermittelt die TCB ob der Benutzer über einen gesicherten Weg arbeitet. Diese Aktivität tritt bei dem Prozess 330 auf. Wenn die TCB ermittelt, dass kein gesicherter Weg aufgebaut ist, wird der Prozess-ID dem Benutzer nicht angezeigt. Diese ist bei dem Prozess 350 dargestellt.
Der Prozess-ID wird im gesicherten Code und Speicher aufbewahrt und ist für nicht gesicherte Subjekte unzugänglich. Jedesmal wenn ein gesicherter Weg zwischen dem SSVR 12 und dem Benutzer aufgebaut wird, zeigt der SSVR 12 den. Prozess-ID des Benutzers bei dem Prozess 340 an. Durch die Betrachtung des angezeigten ID ist der Benutzer sicher, dass ein tatsächlich gesicherter Weg aufgebaut worden ist.

Die Befehlsübertragungseinrichtung

Wie vorstehend diskutiert ist der Befehlsübertragungseinrichtung (CC) 14 eine Schicht in der TCB, welche einen Teil des gesicherten Codes umfasst. Die CC 14 wird dazu genutzt, um eine korrekte Kommunikation gesicherter Befehle zwischen dem SSVR 12 und dem das ungesicherte Subjekt unterstützenden Prozess sicherzustellen. Wie diskutiert, kann ein derartiges ungesichertes Subjekt ein UOS 20 enthalten.
Jeden physischen Terminal 30 ist ein Befehlspuffer zugeordnet. In einigen Ausführungsformen kann jedem Terminal ein Zustandscode zugeordnet sein. In noch weiteren Ausführungsformen ist einer von fünf Befehlszuständen jedem physischen Terminal zugeordnet. Der Befehlspuffer wird zur Speicherung der binäre Repräsentation des gesicherten Befehls verwendet. Der Zustandscode kann dazu verwendet werden, den sich ergebenden Ausführungszustand an das ungesicherte Subjekt zu liefern. Die Befehlszustände umfassen im allgemeinen fünf Möglichkeiten:
1. kein Befehl
2. Befehl weitergegeben
3. Befehl im Ablauf
4. Ignoriere Ende, und
5. Befehl ausgeführt
Diese Zustände werden dazu verwendet, um die verschiedenen Zustände anzuzeigen, welche bei der Ausführung eines gesicherten Befehls angetroffen werden können.
Fig. 7 ist ein Zustandsübergang der Befehlszustände. Eine detaillierte Erläuterung dieser Zustände und Übergänge kann aus der nachstehenden Diskussion erhalten werden.

Verteilung der Verarbeitung gesicherter Befehle

Wie vorstehend diskutiert, "kennt" die TCB 10 zwei Kategorien von Befehlen. Für die Zwecke dieser Beschreibung umfassen "Befehle" durch die Verwendung von Befehlszeilenschnittstellen, Menüschnittstellen, Direkt-Manipulationsschnittstellen oder dergleichen empfangene Benutzeranweisungen.
Die erste Kategorie umfasst "direkte Befehle", welche ausgegeben werden, während der Benutzer in der SSVR 12 Schicht der TCB 10 arbeitet, d. h., interaktiv mit der TCB 10 kommuniziert. Wie vorstehend erwähnt, ist es erwünscht, die Anzahl der für den Benutzer verfügbaren direkten Befehle zu begrenzen. Die Ausführung und Verarbeitung dieser direkten Befehle wird unter Verwendung traditioneller in dem Fachgebiet bekannter Verfahren durchgeführt.
Die zweite Kategorie umfasst "gesicherte Befehle". Diese Befehle werden von einem Benutzer ausgegeben, der in einer nicht gesicherten Computerumgebung, wie z. B. in dem allgemeinen UOS 20 arbeitet. In einer Ausführungsform werden diese gesicherten Befehle von einem Benutzer ausgegeben, der in einer ungesicherten virtuellen Maschine arbeitet.
Fig. 4A und 4B veranschaulichen die für die Ausführungsform eines derartigen Befehls erforderliche Aktivität. Wenn der Benutzer versucht, einen gesicherten Befehl auszuführen, führt der in dem allgemeinen UOS 20 befindliche Syntaxanalysator eine Syntaxanalyse an der gesicherten Befehlsfolge aus und wandelt sie bei dem Prozess 17 in eine binäre Repräsentation um. Bei der Syntaxanalyse des Befehls, prüft der ungesicherte Code in dem UOS 20 die Syntaxsemantik und meldet fehlende Parameter. Syntaxanalysestrategien sind im Fachgebiet allgemein bekannt und werden hier nicht beschrieben.
Aus einer Sicherheitsperspektive ist es nicht erforderlich, dass der Code in dem UOS 20 eine genaue Übersetzung der Benutzerbefehle in eine syntaxanalysierte Repräsentation (binäre Repräsentation) durchführt. Der nachstehend beschriebene Bestätigungsmechanismus ist so ausgelegt, dass er derartige Ungenauigkeiten unabhängig davon, ob sie gutartig oder bösartig sind, auffängt.
Nach der Syntaxanalyse des Befehls gibt ein das UOS 20 unterstützender Prozess einen Aufruf an die TCB aus, welcher der TCB die syntaxanalysierte Präsentation des Befehls und die Identifikation des Terminals, von welcher ein derartiger Befehl ausgegeben wird in dem Prozess 80 weitergibt. In einer Ausführungsform wird die Identifikation des virtuellen Terminals, von welchem der Befehl ausgegeben wurde, an die TCB übertragen. Ein derartiger Aufruf wird durch die CC 14 in der TCB 10 verarbeitet. Die CC 14 ermittelt dann, welches gesicherte Subjekt den Befehl weitergab und kopiert die syntaxanalysierte Repräsentation bei dem Prozess 90 in einen gesicherten Speicher. In einer Ausführungsform wird diese Ermittlung durchge- · führt, indem VTerm aufgefordert wird, das dem virtuellen UOS Terminal zugeordnete physische Terminal zu identifizieren.
Eine solche Weitergabe der binären Repräsentation ist nur dann erfolgreich, wenn die TCB 10 ermittelt, dass das übermittelnde Terminal mit einem aktiven Prozess verbunde n 15t.
Normalerweise ist in Ausführungsformen, welcher die Befehlszustände verwenden, der Befehlszustand des weitergebenden physischen Terminals "kein Befehl", was anzeigt, dass kein gesicherter Befehl von diesem physischen Terminal weitergeben wurde oder sich im Ablauf befindet. Dieser Zustand wird durch den Zustand 400 in Fig. 7 repräsentiert. Wenn der Zustand "kein Befehl" ist, speichert die CC 14 die binäre Repräsentation in dem Befehlspuffer und setzt den Zustand des physischen Terminals auf "Befehl weitergegeben", welcher von dem Übergangszustand 410 repräsentiert wird. Anderenfalls unterbleibt die Weitergabe.
Wenn das in ungesichertem Code ablaufende ungesicherte Objekt die Anzeige aus der TCB empfängt, dass der Befehl erfolgreich weitergegeben wurde, fordert sie den Benutzer auf, die Sicherheitstaste zu aktivieren. In einer Ausführungsform erfordert der gesicherte Code in dem UOS 20, dass der Benutzer die BREAK-Taste aktiviert.
Wenn der Benutzer eine Aufhebungstaste, wie z. B. Ctrl-X oder Ctrl-C anstelle der Aktivierung der Sicherheitstaste drückt, kann der Code in der allgemeinen UOS 20 den gesicherten Befehl aufheben. Diese kann erreicht werden, indem der ungesicherte Code einen Kernaufruf (d. h., eine Anforderung des Sicherheitskerns durch das ungesicherte Objekt) ausgibt, was die CC 14 informiert, dass der Befehl abzubrechen ist. Wenn die CC 14 feststellt, dass der Befehl nicht an den SSVR 12 gesendet wurde, wird der Befehl aufgehoben. In ähnlicher Weise kann, wenn der Benutzerprozess in dem UOS 20 abgebrochen wird, der den Prozess herunterfahrende Code die gesicherte Befehlsanforderung aufheben. Wenn jedoch die CC 14 feststellt, dass der Befehl bereits gesendet wurde, fährt sie fort, da der Benutzer bereits den Befehl ausführt.
In Ausführungsformen, welche Befehlszustände verwenden, führt die Aufhebung der gesicherten Befehlsanforderungen dazu, dass der Befehlszustand von "Befehl weiteraeueben" auf "kein Befehl" geändert wird. Dieser Prozess ist in Fig. 7 dargestellt.
Wenn der Benutzer versucht, einen gesicherten Weg zum Zeitpunkt aufzubauen, an dem der gesicherte Befehl an die TCB übertragen wird, muss sich die TCB entscheiden; jede von diesen Anforderungen kann zuerst verarbeitet werden. Wenn das Sicherheitssignal zuerst verarbeitet wird, kann die TCB 10 die Befehlsweitergabe verschieben und es wird eine Verbindung zu dem SSVR 12 aufgebaut. Wenn die Weitergabe zuerst verarbeitet wird, sieht der Benutzer den Bestätigungsbildschirm wie er nachstehend beschrieben wird.
Wenn der Benutzer nach Aufforderung die Sicherheitstaste aktiviert, wird ein gesicherter Weg zwischen dem physischen Terminal 30 des Benutzers und dem SSVR 12 in der TCB 10 aufgebaut. Diese Konfiguration ist in Fig. 3 in einer dunklen Linie dargestellt. Wenn die VT Schicht 16 die Sicherheits-(Break)-Taste detektiert, meldet sie das dem SSVR 12, welcher dann einen gesicherten Weg in dem dem · physischen Terminal 30 des Benutzers zugeordneten gesicherten Wegunterstützungsprozess aufbaut.
Sobald der gesicherte Weg aufgebaut ist, behält die TCB 10 die ausschließliche Kontrolle über das physische Terminal 30. In einer Ausführungsform wartet der ungesicherte Code in dem UOS 20 auf eine Meldung, dass der Befehl abgeschlossen ist. Somit umgeht der Benutzer im wesentlichen den ungesicherten Code und kommuniziert nur mit gesicherten Code. Somit kann, wenn der Prozess des Benutzers in dem allgemeinen UOS 20 abgebrochen wird oder endet, oder das allgemeine UOS 20 zusammenbricht, der gesicherte Befehl immer noch ausgeführt werden. Der Benutzer wird über keine dieser Unterbrechungen informiert, so lange der gesicherte Befehl abgeschlossen oder abgebrochen worden ist.
Nach dem Aufbau des gesicherten Weges erfordern die Sicherheitsanforderungen des Systems eine Wechselwirkung zwischen dem Benutzer und dem SSVR 12. Dieses ist erforderlich, um Befehle auszuführen, welche den Aufbau eines gesicherten Weges erfordern. Die Kriterien des Orange Book und/oder die Systemsicherheitsziele bestimmen, welche Befehle diese Wechselwirkung erfordern, wie es allgemein nachstehend im Kapitel 4.9 diskutiert wird.
Der Aufbau eines gesicherten Weges in diesen Fällen ist aus mehreren Gründen nützlich. Erstens ermöglicht er es dem sicheren Server dem den Befehl gebenden spezifischen Benutzer zu identifizieren. Zweitens ermöglicht es der sichere Weg dem Benutzer, die geforderte Aktion in einer gesicherten Weise zu prüfen und zu bestätigen (oder zurückzuweisen). Dieses reduziert die Möglichkeit, dass böswillige ungesicherte Software eine Befehlsanforderung ändert, und ermöglicht die Detektion von Syntaxanalysefehlern.
Fig. 4B veranschaulicht die Aktivität, welche nach der Übergabe der Kontrolle an die TCB 10 auftritt. Wie vorstehend diskutiert, baut die TCB 10 zuerst einen gesicherten Weg bei dem Prozess 120 auf. Der TCB prüft dann, ob ein gesicherter Befehl durch den Benutzer weitergegeben wurde. Ungesicherter Code kann dann auf die Beendigung des Befehls warten.
Sobald ein gesicherter Weg aufgebaut worden ist, ruft der SSVR 12 die CC 14 auf, die binäre Repräsentation bei dem Prozess 130 zurückzugeben. In einer Ausführungsform wird die CC 14 zuerst den Befehlszustand des physischen Benutzerterminals 30 ermitteln. In noch einer weiteren Ausführungsform wird die CC 14, wenn der Befehlszustand "Befehl weitergegeben" 410 (Fig. 7) ist, an den SSVR 12 die binäre Repräsentation zurückgeben und den Befehlszustand auf "Befehl im Ablauf" 420 ändern. Wenn der Zustand "kein Befehl" 400 oder "Befehl ausgeführt" 430 ist, schlägt der Aufruf fehl, und der SSVR 12 wird dem Benutzer (SSVR > ) anzeigen. Ein Anfangszustand von "Befehl im Ablauf" 420 oder "Ignoriere Ende" 440 impliziert einen Fehler in dem SSVR 12 und kann dazu führen, dass die CC 14 einen Zusammenbruch der TCB 10 verursacht.
Wenn in diesen Ausführungsformen der Befehlszustand "Befehl weitergegeben" 410 war, gibt die CC 14 an den SSVR 12 die binäre Repräsentation des angeforderten Befehls zurück.

Anzeige eines Befehls für den Benützer.

Sobald der syntaxanalysierte Befehl dem SSVR 12 zurückgegeben ist, ermittelt der SSVR 12 bei dem Prozess 140 (Fig. 4B) ob der Befehl eine Bestätigung erfordert. Eine Bestätigung sollte allgemein für Befehle erforderlich sein, welche eine Modifikation von Information anfordern. Befehle, welche die Information nicht verändern, wie z. B. die Betrachtung von Information sollten nicht generell eine Bestätigung erfordern. Für die Zwecke der Bestätigung sollte eine Umleitung der Anzeige in eine Datei als Betrachtungsinformation in Betracht gezogen werden.
Die Entscheidung, ob ein gegebener Befehl eine Aktivierung der Sicherheitstaste für die Ausführung erfordern sollte, hängt von der grundsätzlichen Sicherheitsstrategie des Systems ab. In einer Ausführungsform sind durch eine Sicherheitstaste gesicherte Befehle ein Mechanismus zur Verwendung durch Systemmanager, Sicherheitsmanager, Operatoren und Besitzer spezieller Privilegien.
Im allgemeinen ist ein Befehl, welcher kein direkter Befehl ist, ein Sicherheits-relevanter Befehl, wenn er:-
a. eine Sicherheitskern-Datenbank in einer sicherheitsrelevanten Weise verändert; oder
b. eine Information anzeigt, auf welche Systemmanager, Sicherheitsmanager oder Operatoren eine Sicherheitsentscheidung stützen.
Wenn der Befehl einer ist, welcher keine Bestätigung erfordert, führt die TCB die Systemsicherheitsstrategie durch und ermittelt bei dem Schritt 145, ob der Benutzer die erforderlichen Zugriffsrechte zur Ausführung des Befehls hat. Wenn dieses der Fall ist, versucht die TCB bei dem Prozess 150 die binäre Repräsentation auszuführen. Da bestimmte Befehle, z. B. Befehle, welche lediglich Information anzeigen, nicht den Zustand des Systems verändern, ist keine Benutzerbestätigung erforderlich. Es besteht kein Sicherheitsproblem, wenn diese Befehle nicht bestätigt werden, da das System allen Benutzern nur die Betrachtung von Information erlaubt, auf welche diese Zugriff haben.
Es gibt bestimmte Befehle, die den Zustand des Systems verändern, welche aber keine Bestätigung erfordern. Einige Befehle können es dem Benutzer erlauben, eine Informationsanzeige in eine Datei umzuleiten, auf welche der Benutzer eine Zugriffserlaubnis hat. Diese Dateien sind in dem Fachgebiet als "Listendateien" bekannt. Im allgemeinen ist das Einschalten einer Listendatei ein bestätigter Befehl.
In Situationen, in welchen eine Listendatei eingeschaltet wurde (d. h., die Ausgabe wird in eine Listendatei umgeleitet) können Befehle, welche normalerweise Information anzeigen durch Schreiben in die Listendatei den Zustands des Systems verändern. In diesen Fällen ist die Bestätigung dieser Befehle im allgemeinen nicht erforderlich, da der Informationsfluss durch die Sicherheitsstrategie der TCB eingeschränkt ist.
Wenn ein die Anzeige von Information erfordernder Befehl von der TCB 10 ausgeführt wird, antwortet der SSVR 12 durch Anzeige einer kompletten Repräsentation des angeforderten Befehls sowie der angeforderten Information, d. h., einer standardmäßigen für Menschen lesbaren Repräsentation des Befehls. In einer Ausführungsform zeigt der SSVR 12 den Funktionscode, Befehlsmodifikatoren und Befehlsparameter in einer unzweideutigen Notierung an. Falls verwendet, kann auch der Prozess-ID angezeigt werden.
Somit ist der Benutzer, wenn der Befehl des Benutzers nicht korrekt syntaxanalysiert, oder in einer nicht zulässigen Weise modifiziert wurde, in der Lage, den Unterschied wahrzunehmen. Dieses hindert ein nicht gesichertes Subjekt daran, einen Benutzer zu täuschen, indem es den Benutzer glauben lässt, dass er oder sie die Ergebnisse eines übertragenen Befehls betrachtet, wenn in der Tat der Befehl tatsächlich geändert wurde.
Wenn der angeforderte Befehl einer ist, für welchen eine Bestätigung erforderlich ist, zeigt der SSVR 12 bei dem Prozess 170 eine standardmäßige für Menschen lesbare Repräsentation an dem Benutzerterminal von dem an, was auszuführen ist. Der den jeweiligen Befehl repräsentierende Code sollte eine unterschiedliche Anzeige erzeugen, sofern nicht die Befehle dieselbe Auswirkung haben. Wie vorstehend diskutiert, ist die nochmalige Anzeige der Aktion, die eine binäre Repräsentation durchführt, weniger komplex als die Syntaxanalyse des ursprünglichen Befehls. Diese beruht zum Teil darauf, weil es per Definition nur eine standardmäßige für Menschen lesbare Repräsentation für jeden syntaxanalysierten Befehl gibt.
Durch die Syntaxanalyse des Befehls im ungesicherten Code und Verifizierung der Anforderung im gesicherten Code wird die Gesamtkomplexität der TCB 10 verringert. Die Anzeige von dem "was zu tun ist" kann natürlich von einem Befehl zum nächsten variieren.
Wenn die Aufgabe des Befehls die Hinzufügung einer Aufzeichnung zu einer Datenbank oder die Erzeugung eines Objektes ist, kann die Anzeige das enthalten, was die neue Aufzeichnung enthalten wird, oder was die Attribute des Objektes sind, wenn der Befehl bestätigt wird.
Wenn eine spezielle Datenbank oder ein Objekt zu modifizieren ist, kann die Anzeige zeigen, wie die aktualisierten Daten aussehen, oder was die Attribute des Objektes sein werden, wenn der Befehl bestätigt wird. Für Befehle, welche ein existierendes Objekt entfernen, oder eine existierende Datei löschen, kann die Anzeige die Aufzeichnung oder das Objekt darstellen.
Im allgemeinen kann sowohl für das Hinzufügen/Erzeugen als auch das Modifizieren, das den weitergegebenen Befehl repräsentierende Datenpaket Felder für die Objektattribute, wie z. B. dessen Namen, dessen Größe und dessen Schutz, enthalten. Für jedes dieser Felder kann das Paket auch ein Flag enthalten, welches anzeigt, ob das Feld von Bedeutung ist. Diese bedeutungsvollen Felder anzeigenden Flags sind auch als "Feldselektoren" bekannt.
Bei der Hinzufügung/Erzeugung von Befehlen kann die TCB Vorgabewerte für nicht selektierte Felder liefern. In Befehlen, welche einen Datenbankeintrag oder ein Objekt ändern können nicht selektierte Felder ihre vorherigen Werte beibehalten.
Zur Unterstützung des Benutzers können die gewählten Felder hervorgehoben werden, wenn sie für die Bestätigung angezeigt werden. Eine derartige Hervorhebung kann durch · im Fachgebiet bekannte Verfahren (z. B. durch die Verwendung von Escape-Sequenzen, welche eine invertierte Videodarstellung starten und beenden) erreicht werden. Diese Hervorhebung zieht die Aufmerksamkeit des Benutzers auf die Felder, die keinen Vorgabewerte oder veränderte Werte aufweisen und ttägt dazu bei, den Benutzer vor Tricks durch ungesicherte Code zu schützen.
Wenn eine Prüfaufzeichnung der Bestätigungsanzeige über die (nachstehend diskutierte) Senke erzeugt wird, können die Escape-Sequenzen für eine invertierte Videodarstellung durch Striche in der nächsten Zeile ersetzt werden. Beispiel:
Diese Veränderung ermöglicht, dass die Prüfaufzeichnung korrekt auf einer Vielfalt von Geräten sogar auf einfachen Zeilendruckern dargestellt wird.
Alternative Ausführungsformen sind vorstellbar, in welchen der TCB jeden Feldwert prüft: bei Hinzufügungs/Erzeugungs- Befehle werden die Felder, welche von Standardwerten abweichende Werte enthalten, hervorgehoben; und bei Modifizierungsbefehlen werden die Felder, welche eine Änderung bewirken, hervorgehoben. Dieser "Feldvergleich"-Lösungsansatz führt im allgemeinen zu einer geringeren Hervorhebung.
Im allgemeinen wird für jeden Befehl, jedes Paketfeld auf dem Bildschirm angezeigt, außer Felder, welche von dem speziellen Befehl ignoriert werden.
In den Fällen, bei denen keine Datenbank modifiziert wird, kann die von dem SSVR 12 erzeugte Anzeige in menschlicher Sprache (z. B. in Englisch) ausdrücken, welche Aktion zu unternehmen ist. Auf diese Weise wird die Möglichkeit einer fehlerhaften Bestätigung reduziert, da der Benutzer aufgefordert wird, die Ergebnisse (eine verständliche festgelegte Aktion) zu bestätigen, und nicht einen möglicherweise geheimnisvollen Befehl.
Der SSVR 12 kann auch eine Liste von Benutzerschutzattributen (wie z. B. der Privilegien, die der Benutzer freigegeben hat) anzeigen, so dass der Benutzer weiß, welche Rolle er oder sie ausübt. Der Benutzer muss ausdrücklich (mit Ja oder Nein) die angeforderte Aktion bestätigen. In einer allgemeinen Ausführungsform zeigt die TCB 12 zur Bestätigung der Ergebnisse an, welche auftreten würden, wenn der Befehl ausgeführt wird.
Im allgemeinen wird jede Information in der binären Repräsentation, die dargestellt wird, zuerst validiert.
Diese Information wird einmal geprüft, um sicherzustellen, dass bestimmte Anforderungen erfüllt werden, z. B. um sicherzustellen, dass die Anzahl von Array-Elementen innerhalb von Array-Grenzen liegen (da außerhalb der Grenzen liegende Bedingungen eine Möglichkeit einen Eintritt in die TCB durch illegale Software schaffen können).
Vor der Darstellung der Inhalte eines die binäre Repräsentation des Befehls enthaltenden Paketes kann alles, was eine Fehlfunktion des Formatierungscodes bewirken könnte, validiert werden. Im allgemeinen könnten solche Kandidaten für die Validierung alles enthalten, was zur Indizierung auf irgend etwas anderes verwendet wird. Zu spezifischen Beispielen zählen die Implementation variierender Strings (ein Zählwert gefolgt von einem Array von Zeichen; der Zählwert wird darauf geprüft, ob er kleiner oder gleich als die Größe des Zeichenarrays ist) der Sprache PASCAL und Zahlen, welche Schlüsselwörter repräsentieren (deren Wert wird geprüft, bevor er zu Indizierung in ein Array von Schlüsselwort-Textstrings verwendet wird. Ferner sind Verfahren zur Validierung im Fachgebiet allgemein bekannt und werden hierin nicht diskutiert.
In einer Ausführungsform sind die Antworten, die ein Benutzer auf die Bestätigungsanforderung machen kann "Ja", "Nein", Ctrl-C, Ctrl-Y oder die BREAK-Taste. Es gibt auch nicht standardmäßige Antworten in dieser Ausführungsform. Für jede Benutzerantwört kann der Sicherheitsserver eine die Antwort nochmals wiedergebende Meldung anzeigen. Wenn die Antwort "Ja" oder "Nein" war, zeigt der Sicherheitsserver 12 eine Anzeige der Computersitzung in dem UOS 20, wenn diese nach dem Abschluss des Befehls wieder aufgenommen wird.
Wenn jedoch der Benutzer Ctrl-Y, Ctrl-C oder die BREAK- Taste aktiviert, wird der Befehl abgebrochen. In einer Ausführungsform ändert dann die CC den Befehlsstatus auf negativ. Dieses kann erfolgen, um dem Weitergabeprozess mitzuteilen, dass der Befehl abgebrochen worden ist. In diesen Fällen wird eine direkte Sitzung mit dem SSVR 12 bei dem Prozess 300 aufgebaut. In diesen Fällen muss der Benutzer explizit einen Wiederaufnahmebefehl geben, um zu der Sitzung in dem UOS 20 zurückzukehren.
Wenn der Benutzer die Ergebnisse oder den Befehl bestätigt, indem er mit "Ja" antwortet oder wenn der Befehl keine Bestätigung erfordert, setzt die TCB 10 bei dem Prozess 145 die Systemsicherheitsstrategie durch. Bei diesem Prozess ermittelt die TCB 10, ob der Benutzer die · erforderlichen Zugriffprivilegien zur Ausführung der angeforderten Aktivität besitzt. Wenn der Benutzer die erforderlichen Zugriffsrechte besitzt, versucht der SSVR 12 zusammen mit weiteren Codes in der TCB 10 den Befehl in einer herkömmlichen Weise auszuführen.
Nach der versuchten Ausführung des Befehls kann der SSVR 12 die CC 14 über den Ausführungsstatus informieren. In einigen Hochsicherheits-Situationen verhindern Bedenken bezüglich des Informationsflusses von gesichertem zu ungesichertem Code die Information der CC 14. Die CC 14 kann den Befehlsstatus ändern, um die Antwort des SSVR 12 anzuzeigen. Zusätzlich verändert die CC 14 in alternativen Ausführungsformen den Befehlszustand von "Befehl in Ablauf" 420 (Fig. 7) in "Befehl ausgeführt" 430. In diesen Fällen benachrichtigt die CC 14 das weitergebende ungesicherte Subjekt mittels herkömmlicher Verfahren (oder durch Weiterzählen eines Ereigniszählers für diesen Prozess). Der SSVR 12 baut dann die Terminalverbindung mit der Computersitzung in dem UOS 20 wieder auf, von welcher der Befehl aus durchgeführt wurde.
In Ausführungsformen, welche den Zustandscode verwenden meldet der Sicherheitsserver, wenn der Benutzer mit "Nein" antwortet, der Sitzung in dem UOS 20, dass der Befehl nicht ausgeführt wurde (negativer Zustandscode). Wenn Befehlszustände ebenfalls verwendet werden, verändert der SSVR 12 den Befehlszustand auf "Befehl ausgeführt", und baut in dem Prozess 120 die Benutzersitzung in dem allgemeinen UOS 20 wieder auf.
Wenn der von dem Benutzer angeforderte Befehl ein Befehl ist, welcher eine der Systemdatenbanken beeinflusst, und die Datenbankaufzeichnung durch irgendeinen anderen Prozess oder durch den Benutzer zwischen dem Zeitpunkt, an dem die Bestätigungsanzeige erschien und der aktuelle Benutzer dem Befehl bestätigte, verändert wurde, stellt dann der SSVR 12 eine Meldung dar, welche anzeigt, dass eine Veränderung durchgeführt wurde und fordert eine Bestätigung an. In diesem Falle wartet der SSVR 12 auf eine Antwort, als ob es das erstemal wäre, dass die Information dargestellt wurde.
Um sicherzustellen, dass dann, wenn zwei Benutzer versuchen, dasselbe Element gleichzeitig zu modifizieren, nur eine Anforderung zurückgewiesen wird, kann die TCB als "Modifizierungszählwerte" (mod-counts) bekannte Identifikatoren benutzen.
Jedes Element von Schlüsseldatenbanken (oder Registrierungseinheiten) kann einen Modifizierungszählwert enthalten. Dieser "mod-count" wird bei jeder Modifikation weiter gezählt und identifiziert somit, wie viele Modifikationen an der Datenbank vorgenommen worden sind. Somit erhält der SSVR 12, wenn ein Benutzer versucht, ein Datenbankelement zu verändern, zuerst den Modifizierungszählwert dieses Datenbankelementes. Nachdem der Benutzer die Anforderung bestätigt hat, prüft die TCB 10 den Modifizierungszählwert in der Anforderung gegen den aktuellen Modifizierungszählwert.
Ein unterschiedlicher Modifizierungszählwert zeigt an, dass eine Veränderung an dem Datenbankelement vorgenommen wurde, und der Benutzer wird aufgefordert, die Anforderung neu zu bestätigen, da dass zuvor von dem Benutzer bestätigte Ergebnis nicht das ist, was das aktuelle Ergebnis wäre.
Um böswillige Benutzer oder Subjekte vor der Verhinderung der Ausführung von gesicherten Befehlen abzuschrecken, werden zwei Maßnahmen unternommen. Erstens können bestimmte Zugriffsrechte erforderlich sein, um bestimmte Datenbankelemente zu verändern. Zweitens sollte der Modifizierungszählwert nicht weitergezählt werden, wenn eine Modifizierung angefordert wird, welche das Datenbankelement nicht verändert. Auf diese Weise werden Versuche durch böswillige Subjekte die Ausführung eines gesicherten Befehls zu verhindern, indem sie rasch und vereinzelt eine Inkrementierung des Modifizierungszählwertes bewirken, verhindert.
Sobald eine Aktivität in dem SSVR 12 abgeschlossen ist, wird die Benutzersitzung in dem allgemeinen UOS 20 wieder aufgebaut. In einer Ausführungsform kann dieses davon begleitet sein, dass die CC 14 das nicht gesicherte Subjekt über den Zustand des weitergegebenen Befehls informiert. Der ungesicherte Code in dem allgemeinen UOS 20 weckt dann den ungesicherten Prozess auf, der in dem UOS 20 bei dem Prozess 160 läuft. In einer Ausführungsform fordert, bevor der TCB 10 den Benutzer an das ungesicherte Subjekt übergibt, der SSVR 12 den Benutzer auf, einen Wagenrücklauf einzugeben. Dieser Schritt ist erforderlich, um den Benutzer zu informieren, dass er/sie in eine ungesicherte Umgebung versetzt ist.

Der SSVR als eine Prüfungs-Aufzeichnungsvorrichtung

In einer Ausführungsform führt der SSVR 12 einen Bericht auf der Befehlsebene (d. h., er erzeugt einen Bericht, indem er in eine Audit- oder Log-Datei einschreibt. Bei Direktbefehlen überprüft der SSVR 12 sowohl die Befehlszeile als auch den Endzustand des Befehls. Für gesicherte Befehle (sicherheitsrelevante Befehle) überprüft der SSVR · sowohl die Bestätigungsanzeige als auch den Endzustand des Befehls.
Zum Aufzeichnen der Bestätigungsanzeige definiert der SSVR 12 einen Abschnitt des Speichers, um die von dem SSVR 12 an das Benutzerterminal gesendeten Informationsfolgen zu speichern. In einer Ausführungsform ist dieser Abschnitt des Speichers als die "Senke" bekannt. Nur die Zeichenfolgen, welche die Bestätigungsbildschirme des SSVRs aufweisen, werden in der Senke untergebracht.
Zeichenfolgen können an die Senke nur angehängt werden, wenn die Senke geöffnet ist. Die Senke ist geöffnet, wenn der SSVR 12 mit der Ausführung eines gesicherten Befehls beginnt. Die Senke kann geschlossen werden, nachdem der Benutzer auf die Bestätigungsaufforderung reagiert hat, oder vor der Anzeige einer bestimmten angeforderten Information. Die in der Senke gespeicherte Information enthält nicht die Benutzereingabe auf irgendwelche Anforderung. Die in der Senke gespeicherte Information wird für Prüfzwecke aufgehoben und kann gemäß herkömmlicher Prüfpraktiken genutzt werden.
Bestätigung durch andere als die weitergebenden Benutzer In einigen Situationen kann es erwünscht sein, dass andere Benutzer als die weitergebenden Benutzer einen sicherheitsrelevanten Befehl bestätigen. Eine solche Situation kann auftreten, wenn eine bestimmte Anwendung oder eine Befehlsdatei vorliegt, die einen privilegierten Befehl enthält, die aber von einen großen Anzahl von Benutzern ausgeführt werden muss. In den Fällen, in welchen es undurchführbar sein kann, allen Benutzern die erforderlichen Zugriffsrechte zu geben, kann es möglich sein, nur einen Benutzer die notwendigen Rechte zu geben und ihm/ihr zu erlauben, diesen Befehl für die anderen Benutzer zu bestätigen.
Eine derartige Bestätigung für nicht weitergebende Benutzer kann erreicht werden, indem man den Code in dem nicht gesicherten Subjekt bezüglich des Benutzers, der den Befehl weitergibt, lügen lässt. Beispielsweise kann der Code in dem UOS 20 sicherstellen, dass bestimmte Befehle immer an die TCB 10 gesendet werden, als ob diese von einem ausgewählten Benutzer weitergegeben worden wären.
Eine Aufgabe dieses ausgewählten Benutzers wäre die Bestätigung dieser bestimmten Befehle für die anderen Benutzer. Nachdem ein nicht ausgewählter Benutzer einen der bestimmten Befehle weitergegeben hat, wird dem ausgewählten Benutzer gemeldet, dass ein weitergegebener Befehl wartet. Der ausgewählte Benutzer kann dann die Bestätigungsanzeige betrachten. Wenn der ausgewählte Benutzer feststellt, dass der übermittelnde Befehl ein legitimer Befehl war, kann er/sie den Befehl bestätigen. Anderenfalls schlägt der ursprüngliche Versuch des Benutzers, den Befehl auszuführen, fehl.

Implementations-Lösungsansätze.

Das vorstehend beschriebene Verfahren zur Ausführung gesicherter Befehle kann durch die Verwendung einer geeigneten Software implementiert werden. Die tatsächliche Auslegung und Codierung ist eine Sache der Routine für den Fachmann auf diesem Gebiet mit dem Vorteil dieser Offenbarung. Eine derartige Auslegung variiert natürlich mit der Hardwareplattform und anderen Faktoren in Verbindung mit der spezifisch gewünschten Information.
Fig. 5 veranschaulicht ein derartiges Verfahren für die Implementierung der vorliegenden Erfindung. Eine programmierbare Maschine enthält eine zentrale Verarbeitungseinheit (CPU) 210 und eine Eingabe/Ausgabe-(E/A)-Vorrichtung 220. Die E/A-Einheit 220 ist in der Lage, gespeicherte Programmierungsanweisungen aus bekannten Speichermedien 230 zu lesen und zu übertragen. Die CPU 210 ist in der Lage, diese Anweisungen zu verarbeiten und die auch den Medien 230 repräsentierten Programmierungsschritte auszuführen. Derartige Systeme sind im Fachgebiet allgemein bekannt und werden hier nicht weiter beschrieben.
Zur Implementierung der Erfindung werden die notwendigen Programmierungsschritte auf Speichermedien 230 durch herkömmliche Verfahren gespeichert. Die Speichermedium 230 werden dann durch die E/A-220 gelesen und die Programmierungsanweisungen an die CPU 210 übertragen. Die CPU 210 liest und interpretiert die Anweisungen und kann danach das Verfahren der Erfindung ausführen.

Claims

1. Maschinen-ausgeführtes Verfahren zum Ausführen, in einer gesicherten Umgebung (TCB 10) auf einem Computersystem, eines von einem Subjekt gegebenen Befehls, wobei das Computersystem auch eine nichtgesicherte Computerumgebung (UOS 20) enthält, und das Verfahren gekennzeichnet ist durch:

(a) Syntaxanalysieren eines von dem Subjekt in der nicht gesicherten Computerumgebung gegebenen gesicherten Befehls (70), um einen syntaxanalysierten Befehl zu erzeugen;

(b) Weitergeben des syntaxanalysierten Befehls (80) an die gesicherte Computerumgebung;

(c) Übertragen einer Repräsentation des syntaxanalysierten Befehls (170) über einen gesicherten Weg an das Subjekt;

(d) Empfangen eines Signals von dem Subjekt über einen gesicherten Weg, welches eine Bestätigung oder keine Bestätigung des syntaxanalysierten Befehls (180) anzeigt;

(e) wenn das empfangene Signal keine Bestätigung anzeigt, dann Verhindern der Ausführung des syntaxanalysierten Befehls; und

(f) wenn das empfangene Signal eine Bestätigung anzeigt, dann Ausführen des syntaxanalysierten Befehls in der gesicherten Umgebung.

2. Verfahren nach Anspruch 1, welches ferner vor dem Schritt (a) aufweist:

(g) Empfangen von Subjektidentifikationsdaten in der gesicherten Computerumgebung von dem Subjekt über einen gesicherten Weg und Prüfen der Sicherheit der Subjektidentifikationsdaten, um eine Sitzung (100) auf dem Computersystem als Antwort auf eine erfolgreiche Sicherheitsprüfung zu einzurichten und

(h) Empfangen des gesicherten Befehls von dem Subjekt in der nicht gesicherten Computerumgebung über einen nicht gesicherten Weg.

3. Verfahren nach Anspruch 1 oder 2 einschließlich der Durchführung einer Sicherheitsprüfung an dem syntaxanalysierten Befehl in der gesicherten Computerumgebung vor dem Ausführen des gesicherten Befehls in der gesicherten Computerumgebung einschließt.

4. Verfahren nach einem der vorstehenden Ansprüche, in welchem das Subjekt ein Benutzer ist, und in welchem die Übertragung der Repräsentation des syntaxanalysierten Befehls das Anzeigen der Repräsentation für den Benutzer mit umfasst.

5. Verfahren nach Anspruch 4, ferner umfassend:

- nach dem Einloggen durch einen Benutzer, Zuweisen eines Prozessidentifikators an den Benutzer in der gesicherten Computerumgebung (310);

- Speichern des zugewiesenen Prozessidentifikators im gesicherten Speicher (320);

- Aufbauen eines gesicherten Wegs zwischen dem Benutzer und der gesicherten Computerumgebung;

- über den gesicherten Weg Anzeigen des Prozessidentifikators dem Benutzer (330); und

- nach dem anschließenden Eintritt des Benutzers in · die gesicherte Umgebung, Anzeigen des Prozessidentifikators dem Benutzer über den gesicherten Weg (340).

6. Verfahren nach Anspruch 5, wobei der Prozessidentifikator eine zufällig oder pseudozufällig erzeugte Gruppe alphanumerischer Zeichen ist.

7. Verfahren nach Anspruch 6, wobei der Prozessidentifikator aussprechbar ist.

8. Verfahren nach einem der Ansprüche 1 bis 7, wobei der Schritt (d) von Anspruch 1 bewirkt wird durch:

- Empfangen eines Signals von dem Subjekt, welches anzeigt, ob die angezeigte Repräsentation genau den gesicherten Befehl repräsentiert oder nicht.

9. Verfahren nach einem der Ansprüche 1 bis 8, wobei die gesicherte Computerumgebung einen Sicherheitskern aufweist.

10. Verfahren nach einem der Ansprüche 1 bis 9, wobei die nicht gesicherte Umgebung (UOS 20) ein allgemeines Betriebssystem aufweist.

11. Verfahren nach einem der Ansprüche 1 bis 10, und zusätzlich mit den nach dem Schritt (b) und vor dem Schritt

(c) von Anspruch 1 ausgeführten Schritten:

- in der gesicherten Umgebung, Übertragen einer Repräsentation des syntaxanalysierten Befehls an ein zweites Subjekt;

- Empfangen eines Signals von dem zweiten Subjekt, welches eine Bestätigung oder keine Bestätigung des syntaxanalysierten Befehls anzeigt; und

- wenn das empfangene Signal aus dem zweiten Objekt keine Bestätigung des syntaxanalysierten Befehls anzeigt, dann Verhindern der Ausführung des syntaxanalysierten Befehls.

12. Computerprogrammprodukt mit einem Computerlesbaren- Medium mit einer darauf befindlichen Computerprogrammcodeeinrichtung, welche dafür angepasst ist, wenn das Programm auf einen Computer geladen wird, den Computer die Prozedur von einem der Ansprüche 1 bis 11 ausführen zu lassen.

13. Computeranordnung mit einer nicht gesicherten Computerumgebung (UOS 20) und einer gesicherten Computerumgebung (TCB 10), gekennzeichnet durch:

- eine Einrichtung zur Syntaxanalyse (70) in der nicht gesicherten Computerumgebung, eines von dem Subjekt gegebenen gesicherten Befehls, um einen syntaxanalysierten Befehl zu erzeugen;

- eine Einrichtung zum Weitergeben (80) des syntaxanalysierten Befehls an die gesicherte Computerumgebung;

- eine Einrichtung zum Übertragen (SSRV12) einer Repräsentation des syntaxanalysierten Befehls über einen gesicherten Weg an das Subjekt zur Bestätigung (170); und

- eine Einrichtung (180) zum Empfangen eines Signals von dem Subjet über einen gesicherten Weg, welcher eine Bestätigung oder keine Bestätigung des syntaxanalysierten Befehls (18) anzeigt; und

- eine Einrichtung, die so betreibbar ist, dass sie die Ausführung des syntaxanalysierten Befehls verhindert, wenn das empfangene Signal keine Bestätigung anzeigt, und den syntaxanalysierten Befehl in der gesicherten Computerumgebung (TCB 10) ausführt, wenn das empfangene Signal eine Bestätigung anzeigt.

14. Computeranordnung nach Anspruch 13, welche ferner aufweist:

- eine Einrichtung, um in der gesicherten Computerumgebung (TCB 10) von dem Subjekt über einen gesicherten Weg Subjektidentifikationsdaten zu empfangen, um eine Sicherheitsprüfung an den Subjektidentifikationsdaten auszuführen, und um eine Computersitzung (100) als Antwort auf eine erfolgreiche Sicherheitsprüfung einzurichten; und

- eine Einrichtung, um den gesicherten Befehl von dem Subjekt in der nicht gesicherten Computerumgebung (UOS20) über einen nicht gesicherten Weg zu empfangen.

15. Computeranordnung nach Anspruch 12 oder 13, ferner mit einer Einrichtung zum Durchführen einer Sicherheitsprüfung an dem syntaxanalysierten Befehl in der gesicherten Computerumgebung vor der Ausführung des gesicherten Befehls in der gesicherten Computerumgebung.

16. Computeranordnung nach einem der Ansprüche 13 bis 15, wobei das Subjekt ein Benutzer ist, und in welcher die Einrichtung für die Übertragung der Repräsentation des syntaxanalysierten Befehls eine Einrichtung für das Anzeigen der Repräsentation für den Benutzer mit umfasst.

17. Computeranordnung nach Anspruch 16, ferner mit:

- einer Einrichtung, um nach dem Einloggen durch einen · Benutzer einen Prozessidentifikator dem Benutzer in der gesicherten Computerumgebung (310) zuzuweisen;

- einer Einrichtung zum Speichern des zugewiesenen Prozessidentifikators in einem gesicherten Speicher (320);

- einer Einrichtung zum Aufbauen eines gesicherten Wegs zwischen dem Benutzer und der gesicherten Computerumgebung;

- einer Einrichtung zum Anzeigen des Prozessidentifikators für den Benutzer (330) über den gesicherten Weg; und

- einer Einrichtung, um dem Benutzer den Prozess-identifikator über den gesicherten Weg (340) nach dem anschließenden Eintritt des Benutzers in die gesicherte Umgebung anzuzeigen.

18. Computeranordnung nach einem der Ansprüche 13 bis 16, ferner mit:

- einer Einrichtung zum Empfangen eines Signals von dem Subjekt, welches anzeigt, ob die übertragene Repräsentation genau den gesicherten Befehl repräsentiert oder nicht.

19. Computeranordnung nach einem der Ansprüche 13 bis 18, wobei die gesicherte Computerumgebung einen Sicherheitskern aufweist.

20. Computeranordnung nach einem der Ansprüche 13 bis 19, wobei die nicht gesicherte Umgebung (UOS 20) ein allgemeines Betriebssystem aufweist.

21. Computeranordnung nach einem der Ansprüche 13 bis 20, ferner mit:

- einer Einrichtung, um in der gesicherten Umgebung eine Repräsentation des syntaxanalysierten Befehls an ein zweites Subjekt zu übertragen;

- einer Einrichtung zum Empfangen eines Signals von dem zweiten Subjekt, welches eine Bestätigung oder keine Bestätigung des syntaxanalysierten Befehls anzeigt; und

- einer Einrichtung, um eine Ausführung des syntaxanalysierten Befehls zu verhindern, wenn das empfangene Signal von dem zweiten Subjekt keine Bestätigung des syntaxanalysierten Befehls anzeigt.