Die Roblet®-Technik bezieht einen großen Teil ihrer Leistungsfähigkeit aus der Tatsache, daß Java™-Code zur Laufzeit mit großer Einfachheit zu Roblet®-Servern transportiert und sofort zur Ausführung gebracht werden kann. Genau das könnte aber auch Sicherheitsrisiken mit sich bringen, wenn nicht auf Server-Seite eingebaute Sicherheitsmechanismen vorhanden wären. Dieses Kapitel beschreibt die Mechanismen.
Sandbox für Roblets®
Nicht erst die Roblet®-Technik ist auf Probleme mit transportiertem Code gestoßen. Java™ ist seit der ersten Stunde damit konfrontiert. Beispiele für ähnliche Fälle sind Applets und RMI (remote method invocation). In jedem Fall ist es notwendig, daß der "fremde" Code in der JVM oder gar dem unterliegenden Betriebssystem und seinen Ressourcen, Schaden anrichten kann. Allein schon das Lesen von Daten kann dabei ein Schade sein.
Java™ wurde aus diesem Grund in der JVM und in der Java™-Bibliothek mit Mechanismen ausgestattet, die eine völlige Abgrenzung des "fremden" Codes vom "eigenen" Code erzwingen. Für Applets, die in einer Browser laufen, hat sich dafür der Begriff Sandbox eingebürgert. Diese in Browsern millionenfach bewährte Sandbox-Technik wird auch im Roblet®-Server für den Betrieb der Roblets® eingesetzt.
Roblets® können daher keinerlei Ressourcen direkt zugreifen. Konkret sind keine direkten Zugriffe auf Java™-Eigenschaften, Dateien, Netzwerk, JNI-Schnittstellen u.v.a.m möglich. Zugriffe auf dieser Art werden über Einheiten ermöglicht. Einheiten werden in Modulen bereitgestellt. Mehr dazu im Kapitel Entwicklung und Überblick für Anwendungsentwickler.
Arbeitsweise des Servers
Bei der Ausführung bzw. genauer beim Start des Servers wird zunächst geprüft, ob ein externer Sicherheits-Manager per Java™-Eigenschaft java.security.manager gesetzt wurde. Ist dies der Fall, so wird vom Server nichts weiter unternommen, sondern die dadurch gesetzten Sicherheitsmerkmale inkl. Sicherheitsrichtlinien werden akzeptiert und gelten dann für den Server und die Module. Mehr dazu weiter unten.
Wurde jedoch kein Sicherheits-Manager "von außen" gesetzt, so wird ein eigener gesetzt. Dieser läßt für den Server und die Module alles zu. Im diesem Fall können also der Server und die von ihm geladenen Module auf jegliche Ressourcen direkt ohne Einschränkung zugreifen.
Gleichzeitig wird für beide eben genannten Fälle trotzdem für jedes einzelne Roblet® stets ein separater Sicherheitsbereich eingerichtet, der die Zugriffsmöglichkeiten auf eine "Sandbox" einschränkt. Dadurch kann kein Roblet® Ressourcen zugreifen, die nicht über den Server und die Einheiten in den Modulen vermittelt werden. Es sind deshalb trotzdem keine Datei- und Netzwerkzugriffe u.v.a.m. ohne entsprechende Einheit/Modul möglich.
Sicherheitsmanager von "außen" für spezielle Sicherheitsrichtlinien
Die in diesem Kapitel gemachten Angaben sind eine Vereinfachung. Das Sicherheitskonzept für JVM's läßt aber noch deutlich mehr zu, wobei dafür die Dokumentation des jeweiligen Herstellers der JVM zu konsultieren ist.
Generell kann man mit einem Sicherheitsmanager von "außen" per java.security.manager=mypackage.ASpecialManager sämtliche Möglichkeiten des Schutzes einer JVM ausnutzen. Selten wird jedoch diese ursprüngliche Art der Kontrolle verwendet.
Stattdessen setzt man meist einfach java.security.manager (ohne Angabe eines Klassennamens) und erreicht dadurch, daß von der JVM der Standard-Sicherheitsmanager gesetzt wird. Dieser läßt zu, daß der Nutzer mit Hilfe von Sicherheitsrichtlinien per Java™-Eigenschaft java.security.policy=pathto/MyPolicy die Möglichkeiten für den Server und die Module einschränkt. Die Möglichkeiten von Roblets® werden dadurch indirekt auch beeinflußt, da sie Ressourcen über Einheiten in Modulen zugreifen.
java ... -Djava.security.manager -Djava.security.policy=pathto/MyPolicy ...
In der Einrichtungsphase der Sicherheitsrichtlinien ist oftmals die Java™-Eigenschaft java.security.debug mit ihren vielen Möglichkeiten hilfreich. Hier ein einfaches, brauchbares Beispiel:
java ... -Djava.security.debug=access,failure -Djava.security.manager -Djava.security.policy=pathto/MyPolicy ...
Weitere Schutzmöglichkeiten
Möchte oder muß man die Zugriffsmöglichkeiten der JVM noch weiter kontrollieren, so bieten sich erfahrungsgemäß verschiedene Mechanismen der unterliegenden Betriebssysteme an. Für Windows-Systeme bieten sich eine Fülle von Betriebssystemsfunktionen und Programmen anderer Hersteller. Unter Unix-Systeme sei hier stellvertretend genannt:
| Funktion | Nutzen |
|---|---|
| quota | Dateisystemsbeschränkungen |
| Nutzersystem | Dateisystemsbeschränkungen, Ausführungsbeschränkungen u.v.a.m. |
| Firewall | Netzwerksbeschränkungen |
| chroot | Dateisystemsbeschränkungen, Ausführungsbeschränkungen u.v.a.m. |
