48.2 Sicherheitsmechanismen in Java

• 48.2 Sicherheitsmechanismen in Java
  • 48.2.1 Sprachsicherheit
  • 48.2.2 Das Sandbox-Konzept
  • 48.2.3 Veränderungen im JDK 1.1 und 1.2

48.2.1 Sprachsicherheit

Java wurde von Anfang an mit höheren Sicherheitsansprüchen entworfen, als dies üblicherweise bei Programmiersprachen der Fall ist. Einer der Hauptgründe dafür war der Wunsch, den Aufruf von Applets, die aus dem Internet geladen wurden, so sicher wie möglich zu machen. Selbst bösartige Applets sollten nicht in der Lage sein, ernsthafte Angriffe auf den Computer, das Betriebssystem oder die Ressourcen des Anwenders auszuführen.

Sicherheit beginnt in Java schon bei der Implementierung der Sprache. Anders als in C oder C++ gibt es beispielsweise keine direkten Zugriffe auf den Hauptspeicher und keine Pointerarithmetik. Das Memory-Management arbeitet vollautomatisch. Sicherheitslücken, die durch (provozierte) Speicherüberläufe verursacht werden, sind damit nicht ohne weiteres möglich.

Alle Typkonvertierungen werden zur Laufzeit geprüft und unerlaubte Umwandlungen von vorne herein ausgeschlossen. Auch Zugriffe auf Array-Elemente und Strings werden grundsätzlich auf Einhaltung der Bereichsgrenzen geprüft. Zugriffe, die außerhalb des erlaubten Bereichs liegen, führen nicht zu undefiniertem Verhalten, sondern werden definiert abgebrochen und lösen eine Ausnahme aus.

Beim Laden von Bytecode über das Netz wird dieser vor der Ausführung von einem Bytecode-Verifier untersucht. Auf diese Weise wird beispielsweise sichergestellt, dass nur gültige Opcodes verwendet werden, dass alle Sprunganweisungen auf den Anfang einer Anweisung zeigen, dass alle Methoden mit korrekten Signaturen versehen sind und dass Ausdrücke korrekt typisiert sind. Zudem implementiert der Klassenlader einen lokalen Namensraum, der verhindert, dass bestehende Klassen verändert oder ersetzt werden können.

48.2.2 Das Sandbox-Konzept

Traditionell wurde in Java zwischen lokalem Code und solchem, der aus dem Netz geladen wird, bezüglich seiner Sicherheitsanforderungen rigoros unterschieden. Während lokalem Code (also Applikationen und von der Festplatte geladenen Applets) der Zugriff auf alle verfügbaren Ressourcen gestattet ist, dürfen Applets, die aus dem Netz geladen wurden, nur einen kleinen Teil davon verwenden. Sie halten sich gewissermaßen in einem Sandkasten auf, in dem sie nur ungefährliche Spielzeuge verwenden und keinen ernsthaften Schaden anrichten können (daher der Name »Sandbox«).

Zu den »gefährlichen Spielzeugen«, die nicht verwendet werden dürfen, zählen:

• der lesende und schreibende Zugriff auf Dateien des lokalen Computers,
• das Öffnen von TCP/IP-Verbindungen zu einem anderen als dem Host, von dem das Applet geladen wurde,
• das Akzeptieren von TCP/IP-Verbindungen auf privilegierten Portnummern,
• das Lesen benutzerbezogener System-Properties wie »user.name«, »user.home«, »user.dir« oder »java.home«,
• das Erzeugen eines Top-Level-Fensters ohne Warnhinweis,
• das Ausführen externer Programme,
• das Laden von System-Libraries,
• das Beenden der virtuellen Maschine.

Benötigte ein Applet Zugriff auf diese Ressourcen, gab es im JDK 1.0 die Möglichkeit, die zugehörigen Dateien auf der lokalen Festplatte abzulegen. Denn wenn das Applet zur Ausführung nicht aus dem Netz, sondern aus den lokalen Dateien gestartet wurde, galt es automatisch als vertrauenswürdig und hatte Zugriff auf alle ansonsten verbotenen Ressourcen.

Hinweis

48.2.3 Veränderungen im JDK 1.1 und 1.2

Mit dem JDK 1.1 wurde eine neue Möglichkeit eingeführt, Applets Zugriff auf geschützte Ressourcen zu ermöglichen. Dazu müssen alle zum Applet gehörenden Dateien in eine jar-Datei verpackt und mit einer digitalen Unterschrift versehen werden. Wird der Unterzeichner auf dem ausführenden Computer als vertrauenswürdig angesehen (indem sein öffentlicher Schlüssel an geeigneter Stelle bekanntgemacht wurde), kann das Applet die Sandbox verlassen und hat Zugriff auf alle geschützten Ressourcen.

Mit dem JDK 1.2 wurde dieses Konzept weiter verfeinert. Während es im JDK 1.1 schwierig war, die Zugriffsbeschränkungen schrittweise zu lockern, ist das nun viel einfacher. Die Zugriffsbeschränkungen sind konfigurierbar und können mit Hilfe einer Policy-Datei auch ohne Programmänderungen angepasst werden. Sie können wahlweise davon abhängig gemacht werden, von wem die Signatur stammt, als auch davon, woher das Applet geladen wurde. Zudem wurde die prinzipielle Unterscheidung zwischen lokalem und netzwerkbasiertem Code aufgegeben. Obwohl die Sicherheitseinstellungen so konfiguriert werden könnten, dass lokalem Code voller Zugriff auf alle Ressourcen gewährt wird, ist das standardmäßig nicht mehr der Fall.