Einschränkungen für Applets

Java nimmt in verteilten Netzwerkumgebungen insofern eine herausragende Rolle ein, da es durch den hardwareunabhängigen Bytecode möglich ist, fremde Programme über das Netzwerk zu laden und auf der lokalen Maschine auszuführen. Daß diese Möglichkeit des Zugriffs in einem sicheren System mit äußerst strengen Einschränkungen einhergehen muß, dürfte klar werden, wenn man sich vorstellt, ein Java-Applet unbekannter Herkunft und Funktionalität hätte freien Zugriff auf die Dateien eines Anwenders und könnte diese nach Belieben auslesen oder verändern. Deshalb unterliegen über das Netz (im allgemeinen über HTTP) heruntergeladene Applets gegenüber lokalen Applikationen starken Beschränkungen. Folgendes ist ihnen unmöglich [Hen97]:

• Dateien auf dem lokalen Rechner lesen oder schreiben. Dateien oder Verzeichnisse auf dem lokalen Rechner umbenennen, löschen oder anlegen.
• Netzwerkverbindungen zu Rechnern außer dem Applet-Server selbst aufbauen.
• Netzwerkverbindungen auf dem lokalen Rechner mithören oder neue Netzwerkverbindungen annehmen.
• Informationen über den Benutzer (Name, Login-Name, Home-Directory) oder die folgenden System-Attribute ermitteln: user.name, user.home,
  user.dir, java.home, java.classpath.
• Irgendwelche Programme auf dem lokalen Rechner starten. Insbesondere haben Applets keinen Zugriff auf die Methoden Runtime.exec().
• Den Java-Interpreter beenden. Ein Applet kann weder System.exit() noch Runtime.exit() aufrufen.
• Dynamische Link-Libraries nachladen. Ein Applet darf also nicht
  System.load() oder loadLibrary() aufrufen.
• Ein Applet darf niemals einen ClassLoader oder einenn SecurityManager erzeugen.
• Applets dürfen keine Klassen außerhalb der Core-API-Klassen - den Packages java.* zugreifen oder laden.
• Applets dürfen keine Klassen definieren, wenn diese bereits auf dem lokalen System vorhanden sind. Dies verhindert, daß ein Applet seine eigenen Klassen anstelle der (sicheren) Systemklassen benutzt.
• Applets dürfen keine Threads außerhalb ihrer eigenen ThreadGroup erzeugen oder beeinflussen.

All diese Sicherheitsbestimmungen werden dabei im Kontext des Applets (z.B. über applet.getAppletContext() erreichbar), in dem das Applet abläuft von zwei zentralen Instanzen kontrolliert: Der ClassLoader [Js] und der SecurityManager. Der ClassLoader überwacht das Laden des Bytecodes der Klassen und die Zuordnung zu den jeweiligen Namensräumen. Da ein Applet nicht in der Lage sein soll, Systemklassen zu überschreiben oder die Klassen anderer Applets zu manipulieren, wird jedem Applet ein eigener separater Namensraum zugeordnet. Zusätzlich überprüft der sog. Verifier des ClassLoaders die Gültigkeit des Byte-Codes, da es ansonsten einem absichtlich fehlerhaften Bytecode erlaubt wäre, durch Erzwingen eines Stacküberlaufs oder -unterlaufs die Virtual Machine in einen undefinierten und damit gefährdeten Zustand zu bringen. Erst wenn der heruntergeladene Code den Verifier durchlaufen hat, wird er an die Virtual Machine weitergereicht und gelangt zur Ausführung.
Um potentiell gefährliche Aktionen während der Ausführung zu überwachen, wird der SecurityManager verwendet. Er kontrolliert Aktionen wie z.B. Datei- und Netzwerkzugriff und verbietet diese bei fehlender Erlaubnis. Wird ein SecurityManager in einem Java-Programm mittels System.setSecurityManager() installiert, so wird etwa bei jedem lesenden Dateizugriff zunächst die Methode SecurityManager.checkRead() aufgerufen, welche die Gültigkeit des Zugriffs anhand verschiedener Parameter überprüft. Bei fehlender Erlaubnis (was bei einem Applet standardmäßig der Fall ist) wird eine SecurityException ausgelöst, was den Vorgang unterbindet. Ein Programm-Beispiel hierzu findet sich in [Cam96].
Interessant im Hinblick auf verteilte Systeme ist sicherlich die Einschränkung der erlaubten Netzwerkverbindungen eines Applets auf den Server, von dem es heruntergeladen wurde, sowie das Verbot, eingehende Nachrichten entgegenzunehmen. Ersteres bedeutet, daß Nachrichten an andere Server über den Ursprungsserver umgeleitet werden müßten. Die zweite Einschränkung bedeutet, daß ein Applet nur Nachrichten vom Server über eine Verbindung empfangen kann, die es selbst aufgebaut hat. Damit sind zum Beispiel IIOP-Requests, die eine neue Verbindung aufbauen, für ein Applet nicht entgegennehmbar, was zur Folge hat, daß ein solches Applet keine CORBA-Server-Funktionalität implementieren kann. Glücklicherweise gibt es aber Möglichkeiten, diese Einschränkungen zu umgehen bzw. aufzuheben, ohne die Sicherheit des Gesamtsystems zu beeinträchtigen.