Das hier beschriebene Sicherheitsmodell wurde mit dem JDK 1.2 neu eingeführt. Es wird nicht von den in den Browsern integrierten Java-VMs (d. h. Microsoft Virtual Machine bzw. Netscape Communicator 4.x) unterstützt, daher muss für die Nutzung dieses Modells in Applets auf das Java-Plug-in zurückgegriffen werden. Wie in Abschnitt 15.1.5 beschrieben, kann es auch für Applikationen verwendet werden, wenn ein SecurityManager aktiviert wird.

Das Modell beruht auf so genannten Policies. Eine Policy besteht aus Regeln, die jeweils Berechtigungen gewähren. Alles, was nicht ausdrücklich in der Policy gestattet wird, ist nicht erlaubt. Eine Regel besteht aus folgenden Teilen:

• Dem Herkunftsort des Bytecodes (d. h. eine URL oder ein Pfadname bei lokalem Code)
• Einer Berechtigung zu einer bestimmten Operation (z. B. Lesen oder Schreiben einer Datei).
• Einer digitalen Signatur, die der Code tragen muss, damit die Berechtigungen gewährt werden.
• Seit Version 1.4 kann eine Regel zusätzlich auf eine Identität (z. B. eine Benutzer-ID) beschränkt werden, unter der der Code ausgeführt werden muss, damit die Berechtigungen zugeteilt werden.

Herkunftsort und Berechtigung sind stets ein fester Bestandteil einer Regel. Signatur und Identität sind dagegen optional.

Standardmäßig werden Policies in Dateien gespeichert. Das JRE versucht beim Start eines Programms zwei Policy-Dateien auszulesen:

• Die System-Policy-Datei, in der die Grundeinstellungen gespeichert sind. Diese Datei befindet sich im Verzeichnis <JAVA_HOME>/jre/lib/security und hat den Namen java.policy.
• Außerdem hat jeder Benutzer die Möglichkeit, eine eigene private Policy-Datei zu erstellen. Diese Datei muss im Home-Verzeichnis des Benutzers abgelegt werden und den Namen .java.policy tragen.

Insgesamt werden die Einträge beider Policy-Dateien »addiert«, d. h., effektiv hat das Programm jede Berechtigung, die in einer der genannten Dateien steht. Wenn keine dieser Dateien vorhanden ist, kommt eine Default-Policy zur Anwendung, die das Auslesen der System-Properties sowie das Binden von Sockets an nicht privilegierte Ports (d. h. höher als 1023) gestattet.

Abbildung 15.2: Das policytool

Die Policy-Dateien werden im ASCII-Format in einer vorgegebenen Syntax gespeichert. Sie können prinzipiell mit jedem beliebigen ASCII-Editor verändert werden. Einfacher ist die Definition von Berechtigungen jedoch mit dem policytool. Das policytool ist ein Programm, das im JRE enthalten ist und das Editieren von Policy-Dateien erlaubt.

Ein Screenshot des Policy-Tools ist in Abbildung 15.2 zu sehen. Über den Menüpunkt »Datei¦Öffnen« kann man eine bereits bestehende Policy-Datei in das policytool laden. Im Startfenster werden zunächst Regeln nach Herkunftsorten und Signierern angezeigt. Falls eine Regel an einen Benutzer gebunden ist, wird auch dieser angezeigt (so wie in der letzten Regel der Abbildung). Wählt man einen Eintrag aus und betätigt den Button »Richtlinieneintrag bearbeiten«, wird ein Fenster angezeigt, in dem alle Berechtigungen detailliert aufgelistet werden.

Abbildung 15.3: Policy-Einträge

Dieses Fenster ist in Abbildung 15.3 dargestellt. In den oberen zwei Textfeldern gibt man an, für welche Codebase bzw. für welchen Signierer die angezeigten Berechtigungen gelten. Die Codebase wird durch eine URL, der Signierer durch den Alias in der lokalen Public-Key-Datenbank angegeben. Lässt man diese Textfelder leer, so gelten die Berechtigungen für alle Herkunftsorte. Es ist dadurch auch möglich, spezielle Policies nach Signierer und Herkunftsort zu vergeben.

Optional kann die Berechtigung auf eine oder mehrere Identitäten (»Principals«) beschränkt werden. Eine Identität kann beispielsweise eine Benutzer-ID des Betriebssystems sein. Beim Hinzufügen eines Principals ist dessen Typ (z. B. »NTUserPrincipal«) sowie dessen Name anzugeben.

Um eine neue Berechtigung (Permission) hinzuzufügen, muss der Button »Berechtigung hinzufügen« betätigt werden. Beim Anlegen eines neuen Rechts müssen drei Parameter eingestellt werden:

• Die wichtigste Einstellung ist die Berechtigung an sich. Für jede Berechtigung ist eine eigene Klasse definiert, die von der Klasse java.security.Permission abgeleitet ist. Für die Einstellung eines Dateizugriffs ist z. B. die Klasse java.io.FilePermission zuständig.
• Für jede Berechtigung gibt es Targets. Ein Target gibt detailliert an, worauf ein Zugriff erfolgen darf. Im Falle der Klasse java.io.FilePermission würde das Target die Datei angeben, auf die der Zugriff erlaubt wird.
• Der dritte Parameter (Aktion) gibt die Art des Zugriffs an. Bei einem Dateizugriff kommen z. B. die Zugriffsrechte »lesen«, »schreiben« oder »lesen und schreiben« in Frage.

Neben der einzelnen Vergabe von Berechtigungen kann auch die java.security.AllPermission erteilt werden, die alle Berechtigungen einschließt, die vergeben werden können.

Sobald die Einstellungen mit dem policytool vorgenommen und gespeichert wurden, sind die neuen Berechtigungen automatisch aktiv. Folgender Ausschnitt zeigt einen Teil die Standard-Policy-Datei des JRE:

// Standard extensions get all permissions by default

grant codeBase "file:${java.home}/lib/ext/" {
  permission java.security.AllPermission;
};

// default permissions granted to all domains

grant { 
  permission java.lang.RuntimePermission "stopThread";

  permission java.net.SocketPermission "localhost:1024-", "listen";

  permission java.util.PropertyPermission "java.version", "read";
  permission java.util.PropertyPermission "java.vendor", "read";
        
  ...Berechtigungen für weitere System-Properties
};

Ein Beispiel für einen benutzerbezogenen Eintrag ist dem Abschnitt 15.2.4 zu entnehmen.