Projektstudium
SS98 - distributed computingProjektstudium
SS98 - distributed computing
Wenn in Java ein ClassLoader eine Klasse von dem lokalen Classpath läd, so wird diese Klasse als glaubwürdig (trustworthy) eingestuft und wird daraus folglich nicht durch einen Sicherheitsmanager eingeschränk. Anders sieht es aus, wenn der RMIClassLoader eine Klasse aus dem Netzwerk laden möchte. In diesen Fall muß ein Sicherheitsmanager aktiviert sein, sonst wird der Vorgang abgebrochen und eine Exception ausgelößt.
Der Sicherheitsmanager muß als erste Aktion eines Javaprogramms gestartet werden. Dies ist nötig, damit er alle nachfolgenden Aktionen überwachen und regulieren kann. Die Hauptaufgabe des Sicherheitmanagers ist es, zu garantieren, daß die geladenen Klassen den standard Java Sicherheitsgarantien untergeordnet werden. Dies ist auch die gleich Idee, die von RMI verfolgt wird. Da bei der Verwendung von RMI von der Java Virtuellen Machine als Umfeld ausgegangen werden kann, wird kein weiteres oder neues Sicherheitskonzept um die JVM herum gestrickt, sondern "nur" dafür gesorgt ,daß das schon bestehende Sicherheitskonzept auch von Klassen eingehalten wird, die von irgendwo aus dem Netz geladen werden.
Ein Beispeil wäre, das Klassen nur von bewährten oder glaubwürdigen Quellen geladen werden (wie ein Applet-Host) und nicht versuchen sensitive Methoden aufzurufen.
Applets sind immer beschränkt durch die AppletSecurity Klasse. Dieser Sicherheitsmanager gewährleistet, das Klassen nur vom Applet-Host oder dessen gekennzeichneten codebase Host geladen werden. Dies verlangt, daß von den Applet-Entwickler die entsprechenden von dem Applet benötigten Klassen auf dem Applet-Host installiert werden.
Anwendungen hingegen müssen ihren eigenen Sicherheitsmanger definieren oder den restriktiven RMISecurityManager verwenden. Wenn kein Sicherheitsmanager definiert wurde, dann kann eine Anwendung keine Klassen vom Netzwerkquellen laden und ist auf die Klassen im lokalen Classpath beschränkt.
Ein Client- oder Serverprogramm ist normalerweise durch eine Klasse implementiert, die vom lokalen System geladen wird. Daher wird sie nicht durch einen Sicherheitsmanager beschränkt. Wenn das Clientprogramm selbst aus dem Netzwerk mit hilfe der bootstrapping Technik (siehe vorherigen Abschnitt) geladen wird, dann wird das Clientprogramm durch einen Sicherheitmanager beschränkt.
Wir sollten uns noch einmal in Erinnerung rufen, daß sobald eine Klasse vom RMIClassLoader geladen wird, alle Klassen die direkt von dieser Klasse verwendet werden ebenfalls vom RMIClassLoader geladen werden, und so den Restriktionen des Sicherheitsmanagers unterliegen.
Selbst wenn ein Sicherheitsmanager bestimmt wurde, verhindert das setzen des Attributes java.rmi.server.useCodebaseOnly ein laden von einer Klasse von der im Informationsstrom des übertragenen Objektes enthaltenen URL. Es können natürlich noch weiterhin Klassen von der lokal definierten java.rmi.server.codebase. Das Attribut java.rmi.server.userCodebaseOnly kann von beiden Seiten, der Client und der Server, gesetzt werden.
Bei Applets ist das anwenden des Attributes UserCodebaseOnly nicht möglich.
Wenn eine Anwendung seinen eigenen Sicherheitmanager definiert, welcher das Erzeugen von Classloaders verbietet, dann werden Klassen über den Mechanismus der standard Methode Class.forName geladen.
Sollte ein Server seine eigenen Sicherheitspolitik über den Sicherheitsmanager und den Classloader definieren, dann wird das RMI System nach dieser Sicherheitspolitik arbeiten.
Es ist noch zu erwähnen, das die abstrakte Klasse java.lang.SecurityManager, von der alle Sicherheitsmanager abgeleitet sind, keinen Ressourcenverbrauch reguliert. Dafür hat der aktuelle RMISecurityManager keine Mechanismen zur Verfügung, um das laden von Klassen von mißbrauchenden Ressourcen zu vermeiden.
Wir haben gesehen, das der RMISecurityManager die Aufgabe hat die Sicherheit des Java runtime enviroment zu gewährleisten. Dieses wird erreicht, in dem die Sicherheitpolitik von Java sichergestellt wird. Klassen werden also über Sicherheitsmanager und Classloader der Sicherheitspolitik entsprechend eingeteilt und beschränkt. Zum Abschluß dieses Abschnittes wird noch eine minimalistische standard RMISecurityManager Klasse angegeben, damit man ein Gefühl dafür bekommt welche Restriktionen eingestellt werden können. Es sei vorweg genommen, dieser RMI standard Securitymanager erlaub so gut wie gar nichts.
RMI Security Manager Minimalbeispiel
Die schon hier in der Beispielsklasse eines RMISecuritymanagers oft erzeugte SecurityException ist der Art java.rmi.RMISEcurityException und direkt von SecurityException abgeleitet.
Der standard RMISecurityManager kann verwendet werden, wenn die Anwendungen keine spezialisierten Sicherheitsfunktionen benötigen aber die Sicherheit die sie bereitstellen. Dieser einfache Sicherheitsmanager verbietet alle Funktionenen, außer das Definieren von Klassen und das Zugreifen auf Klassen, sodas andere Klassen von remote objects ihre Argumente und Rückgabewerte geladen werden können, soweit es nötig ist. Eine geladene Klasse ist berechtigt Verbindungen aufzubauen, soweit die Verbindung über die RMI-Transport Schicht iniziiert wurde.
Wenn kein Sicherheitsmanager gesetzt wurde, ist das laden von Stubs nicht möglich. Dies sichert, daß ein Sicherheitsmanager verantwortlich für die Aktionen von geladenen Stubs und Klassen, die als Teil eines remote Methodenaufrufes geladen wurden, ist. Ein Sicherheitsmanager wird, wie wir schon gesehen haben über die Methode setSecurityManager gesetzt.
