Freie Schritte unter Aufsicht

Applets sind flügge geworden. Sie haben die "Sandbox" des JDK 1.1 verlassen und dürfen, wenn auch streng bewacht, auf Wunsch des Benutzers die Festplatte seines PCs beschreiben oder die Registratur ändern.

Von: Dr. Klaus Plessner

Gerade hat man sich daran gewöhnt, daß aus dem Internet empfangene Java-Programme in einem allseits abgeschlossenen Sandkasten landen und deshalb auf dem Rechner des Surfers kein Unheil anrichten können. "Java Development Kit 1.0" (JDK), die erste Ausgabe der objektorientierten Web-Sprache aus dem Jahr 1995, ging kein Risiko ein. Alles was von "außen" kam - und der Clou von Java ist ja gerade, daß ein Browser Codeabschnitte genauso wie grafische Seitenbausteine per HTML bezieht -, galt als "nicht vertrauenswürdig" und durfte nicht auf Systemressourcen zugreifen. Lokal abgespeicherte Klassendateien hingegen hatten Narrenfreiheit. JDK 1.1 führte 1997 digitale Signaturen ein und unterschied zwischen Applets mit und solchen ohne Unterschrift. Gestempelte Programme mußten dabei keine Einschränkungen fürchten, signaturlose kamen jedoch in die gute alte Box.

Jedem Code sein Recht

Während der Sandkasten zum Sinnbild für Java-Sicherheit geworden ist, haben die Entwickler dessen Umfriedung abgebaut: Programme dürfen seit Dezember, als Java 2 vom Stapel lief, im Prinzip alles, ob sie nun als Applets aus dem Web kommen oder aus der Werkstatt des Anwenders stammen. Der Benutzer entscheidet, was er einer Applikation erlaubt und was nicht. Dazu entwirft er eine Security-Policy, die den Klassen eines Ursprungs oder "Unified Resource Locators" (URL) Rechte seiner Wahl gewährt. Die Java Virtual Machine sieht daraufhin einem Applet genau auf die Finger und garantiert, daß die geladenen Bausteine die ihnen zugeteilten Freiräume nicht verlassen.

Es bleibt also dem Administrator überlassen, ob er den Klassenbibliotheken von Sun vertraut oder nicht, und wenn ja, ob er ihnen Schreibprivilegien einräumt. Erst mit diesem Sicherheitsmodell, das auch feine Unterschiede zwischen Zugriffsrechten kennt, ist Java fit fürs Intranet. Denn professionelle Applikationen werden kaum mit dem Alles-oder-Nichts-Prinzip der Sandbox auskommen können, weil sie entweder blockiert sind oder die Sicherheit des Unternehmens bedrohen; es sei denn, der Anwender hat sie eigenhändig entwickelt und mit erweiterten Klassen versehen.

Die Policy entscheidet

Mehrere Komponenten des Java-Baukastens tragen dazu bei, daß Programme in einer kontrollierten Umgebung ausgeführt werden:

- Security-Policy-File

- Permission Classes

- Access Controler

- Class Loader

Die Security Policy gründet auf einem Textfile, das der Benutzer per Hand oder mit dem grafischen User-Interface "Policytool" gestaltet. Dort findet eine dreifache Zuordnung statt. Die Herkunft einer Klasse, bezeichnet durch die Zeichenfolge des URL, wird in einer Grant-Anweisung mit einer Liste von Unterzeichnern und mit einer Permission Class verbunden. Zum Beipiel heißt ein Eintrag des Policy-Files:

grant

codeBase "http://www.gateway.de/*" signedBy "Klaus" {

permission java.io.FilePermission "C:\\user\\kpl\\*" "read";

permission java.net.socketPermission "168.192.0.5:80", "accept";

};

Code, der von http://www.gateway.de stammt, und gleichzeitig vom Benutzer Klaus signiert ist, darf nach dieser Regel das lokale Verzeichnis C:\user\kpl\ lesen und vom Server der IP-Adresse 168.192.0.5 auf Port 80 Pakete empfangen. Der Bezeichnung signedBy folgt der Name oder ein Kürzel des Unterzeichnenden. Damit der Access Controler die Signatur überprüfen kann, muß das File auch den Namen des Key-Servers enthalten, der den öffentlichen Schlüssel des Genannten verwaltet. Die definierende Zeile könnte zum Beispiel so aussehen:

keystore "http://www.gateway.de/.keystore" "JKS"

Zusammen mit dem URL des Servers wählt der Benutzer hier das Verfahren der Schlüsselverwaltung. Die Keystores von Sun verwenden das proprietäre Verfahren "Java Key Store" (JKS).

Klassen gewähren Zugriff

Permission Classes eröffnen einer Java-Anwendung den Zugriff auf Systemressourcen wie die Festplatte oder Netzwerkports zu. Sie sind das Rüstzeug des Programmierers, der einer Intranet-Applikation abgestufte Rechte zuteilen will. Ein in Java geschriebenes Benutzer-Interface oder ein Browser implementieren einerseits Permission Classes, damit sie Systemzugriff erlangen. Andererseits sehen sie in der Policy-Datei nach, welchen der geladenen Klassen sie die definierten Permissions zuteilen sollen.

Die von Sun entworfenen Standard-Permission-Classes sind bereits in der Virtual Machine implementiert. Der Anwender kann sie somit in das Policy-File einbauen, falls er mit Java 2 ausgerüstet ist. Was kommerzielle Browser anbelangt, versteht noch keiner den 2er-Dialekt. Einen Ausweg aus der Misere schafft die sogenannte Plug-in-Methode, die Java über ein Interface mit einem Browser koppelt. Das Plug-in gibt’s von Sun, geeignete Surf-Programme sind neuere Ausgaben von "Netscape Navigator" und "Microsoft Internet Explorer".

Die Standard-Permission-Classes sind Unterklassen der Sicherheitsklasse java.security.Permission. Falls ein Entwickler mit den Standards nicht auskommt, kann er weitere Permission-Classes als Unterklasse von java.security.BasicPermission zimmern. Indem er BasicPermissions erweitert, baut er eine Klasse, die sich an die Namenskonventionen der Standardklassen und an die Abfrage der Policy hält. Für die Terminplanung könnte er eine Klasse firma.termine.Permissions ("Ziele") definieren, die mit Ziele = DatumAendern zum Beispiel das Abreißen von Kalenderblättern erlaubt.

Beim Ausführen eines Programms achtet der Access Controler darauf, daß keine der geladenen Klassen mehr darf, als die Security Policy vorgibt. Und noch mehr: Wenn eine Methode A eine Methode B aufruft, die laut Policy weniger Rechte hat, gewährt ihr der Access Controler nur die Rechte von B. Ganz allgemein erhalten entlang einer Folge von Aufrufen im Programmablauf alle beteiligten Klassen die Schnittmenge der ihnen zugewiesenen Permissions. Jeder Klasse ist also nur das erlaubt, was gleichzeitig alle Glieder der Methodenkette dürfen. Damit auch ältere Anwendungen unter Kontrolle bleiben, haben die Entwickler auch den früher verwendeten Security-Manager in Java 2 eingebaut, der jetzt alle Permission-Checks an den Access Controler weiterleitet.

Class Loader besorgen den Bytecode einer vom Programm angeforderten Klasse. Jede Klasse hat ihren eigenen Loader, der für sie spezifische Aufgaben erfüllt. Applets zum Beispiel liegen in der Regel auf einem fernen Rechner und erfordern den Aufbau einer Netzwerkverbindung. Der Class Loader übernimmt folgende Aufgaben:

- Er durchsucht den Bytecode nach unerlaubten Sequenzen, die beispielsweise zu einer privaten Klasse gehören,

- er prüft die Signatur einer Klasse, und akzeptiert diese nur, wenn sie gültig ist und den Vorgaben des Policy-Files entspricht, und

- er gewährt an Hand der Policy-Datei der Klasse ihre Rechte.

Keine Schlüssel für Europa

Auch ans Verschlüsseln haben die Entwickler von Sun gedacht. Die Klassen, die man dafür braucht, gliedern sich in zwei Bereiche. Der eine heißt "Java Cryptography Architecture" (JCA) und ist Teil von Java 2. Er enthält keine Verschlüsselungsfunktionen, sondern nur Interfaces, die das Einbinden von Kodieralgorithmen erleichtern. java.security.cert zum Beispiel definiert als Schnittstelle den Umgang mit X.509-Zertifikaten, java.security.interfaces entwirft providerunabhängige Schnittstellen zum Austausch von RSA- und DSA-Schlüsseln (RSA = Rivest, Shamir und Adleman; DSA = Data Signature Algorithm).

Den eigentlichen Werkzeugkasten für Kryptografen findet man in der "Java Cryptography Extension" (JCE), einer Erweiterung von Java 2, die Sun jedoch nicht aus den USA exportieren darf. Diese Lücke schließen europäische Anbieter kostenlos, zum Beispiel die TU Graz (http://jcewww.iaik.tu-graz.ac.at/jce/jce.htm) oder Australian Business Access (http://www.aba.net.au/). Java hat also das Zeug, um Unternehmen mit hohen Sicherheitsansprüchen zu erobern. Was noch fehlt, sind die Programme. Denn bislang konzentrieren sich Entwickler immern noch auf den Vorgänger JDK 1.1. (kpl)

Literatur

[1] Gong, L.: Java Security Architecture (JDK 1.2); http://java.sun.com/products/jdk/1.2/docs/guide/security/spec/security-spec.doc.html, Sun Microsystems, 1998.

[2] Gong, L.: Secure Java Class Loading; IEEE Internet Computing, November/Dezember 1998.