15.1.4 | Konzepte für erweiterte Applet-Zugriffsrechte |
Wie im vorhergehenden Abschnitt geschildert, hatten die Sicherheitsmechanismen für Applets vor Java 1.2 einen recht binären Charakter. Zwar verfügen der Internet Explorer und der Netscape Communicator beide über eine Option, mit der man global einstellen kann, ob Java-Applets im Browser überhaupt ausgeführt werden können oder nicht, doch gab es vor Java 1.2 keine Möglichkeit, Berechtigungen gezielter zu vergeben.
Aus diesem Grund enstanden in den Java-Implementierungen der beiden genannten Browser voneinander getrennt eigene Konzepte, um Applets gezielt erweiterte Berechtigungen zukommen zu lassen. Diese Browser-eigenen Sicherheitsmodelle weichen vom Ansatz her von dem heutigen Modell des J2SDK ab. Beim Internet Explorer beschränkt sich die Inkompatibilität auf unterschiedliche Granularität in der Vergabe und der Art, wie Berechtigungen vergeben werden. Beim Netscape Communicator müssen sogar Änderungen am Quellcode vorgenommen werden, um dessen Sicherheitsmodell zu benutzen.
Allerdings haben die Browser-eigenen Java-Implementierungen mit ihren Sicherheitsmodellen in der letzten Zeit an Bedeutung verloren. Die 6er-Versionen von Netscape und Internet Explorer verfügen standardmäßig sogar über keine eigene Java-Laufzeitumgebung (beim Internet Explorer 6 muss die Microsoft Virtual Machine zusätzlich heruntergeladen werden, da sie nicht mehr in der Distribution enthalten ist), so dass Suns Java-Plug-in mittlerweile zur Standard-Laufzeitumgebung für Applets geworden ist. Da das Java-Plug-in die Laufzeitumgebung des JRE/J2SDK verwendet, kann damit auch in beiden Browsern das aktuelle Sicherheitsmodell verwendet werden.
Unabhängig davon, welcher der genannten Applet-Betrachter eingesetzt wird, gelten ohne besonderen Einstellungen normalerweise folgende Regeln:Die Möglichkeiten, diese Voreinstellungen bei Internet Explorer und Netscape Communicator zu ändern, werden im folgenden beschrieben. Für den Appletviewer und das Java-Plug-in gelten die Ausführungen im Abschnitt 15.1.6.
- Applets dürfen nicht auf lokale Dateien zugreifen.
- Applets dürfen nur zu dem Rechner Netzwerkverbindungen aufbauen, von dem sie geladen wurden.
Die im Internet Explorer integrierte Java Virtual Machine von Microsoft verfügt über einen eigenen Sicherheitsmechanismus. Diese Virtual Machine ist noch auf dem Stand vom JDK 1.1 und seit Internet Explorer 6.0 nur noch als separates Paket bei Microsoft erhältlich.
Bei der Microsoft Virtual Machine hat der Benutzer die Möglichkeit, die Berechtigungen eines Applets relativ flexibel einzustellen. Es gelten prinzipiell folgende Regeln:Alle Sicherheitseinstellungen werden im Internet Explorer über das Menü »Extras¦Internetoptionen« vorgenommen. Unter »Sicherheit« kann man die einzelnen Zonen anwählen. Der Internet Explorer bietet vier vorkonfigurierte Sicherheitsstufen zur Auswahl. Jede dieser vier Stufen kann angepasst werden. Bei der Anpassung einer Sicherheitsstufe gibt es unter anderem auch Java-Einstellungen. Wählt man dort den Punkt »Benutzerdefiniert« aus, so wird am unteren Bildschirmrand der Button »Java-Einstellungen« sichtbar. Bei Betätigung dieses Buttons erscheint ein Dialog, der es erlaubt, die Sicherheitseinstellungen für Java-Applets nach eigenen Bedürfnissen anzupassen. Dieser Dialog wird in Abbildung 15.1 gezeigt.
- Lokale Applets haben grundsätzlich dieselben Berechtigungen wie eine Stand-alone-Anwendung. Hierzu müssen sich allerdings die Applet-Klassen im CLASSPATH befinden.
- Die Seiten, die man im Internet Explorer über das Netz lädt, werden, abhängig vom Herkunftsort, in eine von vier Zonen eingeteilt. Jeder Zone können eigene Java-Einstellungen zugeordnet werden. Somit können Applets in unterschiedlichen Zonen mit unterschiedlichen Berechtigungen ausgeführt werden.
- Signierten Applets können wiederum andere Berechtigungen zugeordnet werden als nicht signierten Applets, auch wenn sie aus derselben Zone stammen.
Der Internet Explorer bietet nicht so viele Einstellungsmöglichkeiten wie das Sicherheitsmodell von Java, sie können jedoch recht einfach und komfortabel vorgenommen werden.
Auch der Netscape Communicator 4.x verfügte in seiner Java-Implementierung über einen eigenen Sicherheitsmechanismus, der von dem zuvor beschriebene Modell des Internet Explorers abweicht. Seit Version 6 enthält der Netscape-Browser keine eigene Java-Laufzeitumgebung mehr, sondern nutzt zur Ausführung von Java die Laufzeitumgebung von Sun. Damit kann mit Netscape 6 grundsätzlich das im Abschnitt 15.1.6 beschriebene Sicherheitsmodell der Sun-Implementierung verwendet werden, was in den älteren Versionen nur mit dem Java-Plug-in möglich war.
Zur Erweiterung der Berechtigungen von Applets sah die Java-Laufzeitumgebung des Netscape Communicator 4.x ein eigenes, von Netscape entwickeltes API vor: das Capabilities API. Um dieses API zu nutzen, mussten in jedem Fall Änderungen am Quelltext vorgenommen werden. Mit der Verwendung dieses API ist ein Applet natürlich auf den Netscape Communicator festgelegt, da das Capabilities API Netscape-spezifisch ist.
Will ein Applet eine bestimmte, möglicherweise sicherheitsrelevante, Operation durchführen, so muss diese Berechtigung zunächst mit der Methode enablePrivilege() angefordert werden, die in der Klasse netscape.security.PrivilegeManager definiert ist. Diese Klasse ist nicht im J2SDK enthalten und muss gesondert bei Netscape bezogen werden, entweder über einen gesonderten Download bei Netscape oder über die Klassen des Netscape Communicators, in dem das komplette Capabilities API enthalten ist. Die Anforderung einer Berechtigung könnte im Quellcode z. B. folgendermaßen aussehen:PrivilegeManager.enablePrivilege("UniversalPropertyRead");Bei Ausführung dieser Zeile wird die Berechtigung angefordert, auf alle Properties zuzugreifen. Netscape hat für bestimmte Berechtigungen Namen vergeben, die enablePrivilege() als Parameter dienen (die so genannten System Targets). Beim Aufruf von enablePrivilege() erscheint ein Meldungsdialog, in dem der Benutzer darüber informiert wird, welche Aktion das Applet durchführen will. Der Benutzer kann daraufhin dem Applet die Aktion erlauben oder verbieten. Wird die Aktion erlaubt, so hat das Applet so lange die angeforderte Berechtigung, bis die Methode, in der der Aufruf stattfand, beendet ist. Das Sicherheitsmodell des Netscape Communicators ermöglicht es so, einem Applet zur Laufzeit Berechtigungen nur temporär zu erteilen.
Insgesamt ist die Arbeit mit dem Netscape-Sicherheitsmodell am aufwändigsten, da zum einen der Quelltext modifiziert und zum anderen der Benutzer jede Aktion ausdrücklich bestätigen muss.