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
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.
Arbeitsweise
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 nichts weiter unternommen, sondern die dadurch gesetzten Sicherheitsmerkmale inkl. Sicherheitsrichtlinien werden akzeptiert. Wurde jedoch kein Sicherheits-Manager gesetzt, so wird ein eigener gesetzt, der eigene Sicherheitsrichtlinien (policy) verwendet.
Die eigenen Sicherheitsrichtlinien lassen für den Server und die Module alles zu (java.security.AllPermission). Gleichzeitig wird 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 seine Module vermittelt werden. Es sind demnach keine Datei- und Netzwerkzugriffe u.v.a.m. möglich.
Sicherheitsrichtlinien
Will man außerdem eigene Sicherheitsrichtlinien per Java™-Eigenschaft java.security.policy für den Server und die Module setzen, so muß man java.security.manager einsetzen. Das hat die Erzeugung und das Installieren eines Standard-Sicherheits-Managers durch die Java™-Bibliothek bzw. die JVM zur Folge. Der Standard-Sicherheits-Manager liest dann die gewünschten Sicherheitsrichtlinien.
