Richtliniendateien für die Java-2-Sicherheit

Die Spezifikation Java™ 2 Platform, Enterprise Edition (J2EE) Version 1.3 und höher hat ein klar definiertes Programmiermodell der Zuständigkeiten zwischen Ressourcenprovidern und Anwendungscode. Die Verwendung des Java-2-Sicherheitsmanagers für die Umsetzung dieses Programmiermodells wird empfohlen. Gewisse Operationen werden im Anwendungscode nicht unterstützt, weil sie sich störend auf das Verhalten und die Ausführung der Container auswirken. Der Java-2-Sicherheitsmanager wird im Produkt verwendet, um die Zuständigkeiten des Containers und des Anwendungscodes umzusetzen.

Fehler vermeiden Fehler vermeiden: Der Anwendungsserver unterstützt keine angepasste Implementierung des Java-Sicherheitsmanagers.gotcha

Dieses Produkt bietet Unterstützung für die Verwaltung von Richtliniendateien. Es gibt verschiedene Richtliniendateien im Produkt, die entweder statisch oder dynamisch sind. Eine dynamische Richtlinie ist eine Schablone mit Berechtigungen für einen bestimmten Ressourcentyp. In der Schablone für dynamische Richtlinien ist keine relative Codebasis definiert. ´Die Codebasis wird dynamisch aus den Implementierungs- und Laufzeitdaten berechnet.

Statische Richtliniendateien

Tabelle 1. Statische Richtliniendateien.

In dieser Tabelle sind die Positionen der statischen Richtliniendateien aufgelistet.

Richtliniendatei Position
java.policy

[AIX Solaris HP-UX Linux Windows][z/OS]Stammverzeichnis_des_Anwendungsservers/java/jre/lib/security/java.policy. Standardberechtigungen, die an alle Klassen erteilt werden. Die Richtlinie dieser Datei gilt für alle von WebSphere Application Server gestarteten Prozesse.

server.policy Profilstammverzeichnis/properties/server.policy. Standardberechtigungen, die an alle Produktserver erteilt werden.
client.policy Profilstammverzeichnis/properties/client.policy. Standardberechtigungen für alle Produkt-Client-Container und -Applets eines Knotens.
Die statischen Richtliniendateien werden nicht von Konfigurationsservices und Dateireplikationsservices verwaltet. Änderungen, die in diesen Dateien vorgenommen werden, sind lokal und werden nicht auf andere Knoten in der Zelle von WebSphere Application Server Network Deployment repliziert.

Dynamische Richtliniendateien

Tabelle 2. Dynamische Richtliniendateien.

In dieser Tabelle sind die Positionen der dynamischen Richtliniendateien aufgelistet.

Richtliniendatei Position
spi.policy

Profilstammverzeichnis/config/cells/Zellenname
/nodes/Knotenname/spi.policy

Diese Schablone ist für die Ressourcen von Service Provider Interface (SPI) oder Fremdherstellern, die in das Produkt integriert sind, bestimmt. Beispiele für SPIs sind Java Message Service (JMS) in MQ Series und JDBC-Treiber (Java Database Connectivity). Die Codebasis für die eingebetteten Ressourcen werden dynamisch aus den Konfigurations- (Datei resources.xml) und Laufzeitdaten ermittelt. Die Berechtigungen, die in den Dateien spi.policy definiert sind, werden automatisch auf diese Ressourcen und die JAR-Dateien angewendet, die im Klassenpfad eines Ressourcenadapters angegeben sind. Die Standardberechtigung der Datei spi.policy ist java.security.AllPermissions.

library.policy

Profilstammverzeichnis/config/cells/Zellenname/nodes
/Knotenname/library.policy

Diese Schablone ist für die Bibliothek (Java-Bibliotheksklassen) bestimmt. Sie können eine gemeinsam genutzte Bibliothek für die Verwendung in Mehrproduktanwendungen definieren. Für library.policy ist keine Standardberechtigung definiert.

app.policy

Profilstammverzeichnis/config/cells/Zellenname
/nodes/Knotenname/app.policy

Die Datei app.policy definiert die Standardberechtigungen, die allen Unternehmensanwendungen erteilt werden, die auf Knotenname in Zellenname ausgeführt werden.
Anmerkung: Aktualisierungen der Datei app.policy gelten nur für die Unternehmensanwendungen, die auf dem Knoten ausgeführt werden, zu dem die Datei app.policy gehört.
was.policy

Profilstammverzeichnis/config/cells/Zellenname
/applications/Name_der_EAR-Datei/deployments/
Anwendungsname/META-INF/was.policy

Diese Schablone ist für anwendungsspezifische Berechtigungen bestimmt. Die Datei was.policy ist in die EAR-Datei eingebettet.

ra.xml Name_der_RAR-Datei/META-INF/was.policy.RAR.

Für diese Datei kann in der Datei ra.xml eine Berechtigungsspezifikation definiert werden. Die Datei ra.xml ist in die RAR-Datei integriert.

Für die grant-Einträge in den Dateien app.policy und was.policy muss eine Codebasis definiert sein. Wenn grant-Einträge ohne Codebasis angegeben wurden, werden die Richtliniendateien nicht ordnungsgemäß geladen und die Ausführung der Anwendung kann fehlschlagen. Sollen die Berechtigungen allen Anwendungen erteilt werden, verwenden Sie file:${application} als Codebasis im grant-Eintrag.

Syntax der Richtliniendatei

Eine Richtliniendatei enthält mehrere Richtlinieneinträge. Das folgende Beispiel veranschaulicht das Format der Richtlinieneinträge:
grant [codebase <Codebasis>] {
permission <Berechtigung>;
 permission <Berechtigung>;
permission <Berechtigung>;
};

<Codebasis>: Ein URL.
			Beispiel: "file:${java.home}/lib/tools.jar"
						      Wenn [codebase <Codebase>] nicht angegeben ist, gelten die aufgelisteten
               Berechtigungen allgemein.
												Wenn der URL mit einem JAR-Dateinamen endet, gehören nur die Klassen in der
               JAR-Datei zur Codebasis.
                              Wenn der URL mit "/" endet, gehören nur die Klassendateien im angegebenen Verzeichnis zur Codebasis.
                              Wenn der URL mit "*" endet, gehören alle JAR- und Klassendateien im angegebenen Verzeichnis zur Codebasis.
                              Wenn der URL mit "-" endet, gehören alle JAR- und Klassendateien im angegebenen Verzeichnis sowie in dessen
               Unterverzeichnissen zur Codebasis.
<Berechtigungen>: Besteht aus
							   							Berechtigungstyp 	: Klassenname der Berechtigung
     										Zielname         	: Name des Ziels
     										Aktionen         	: Auf dem Ziel zulässige Aktionen
			Beispiel:       						java.io.FilePermission "/tmp/xxx", "read,write"
Nähere Einzelheiten zu den einzelnen Berechtigungen finden Sie in den Spezifikationen des Developer Kit.

Syntax dynamischer Richtlinien

Sie können für eine Unternehmensanwendung Berechtigungen für spezielle Ressourcentypen in dynamischen Richtliniendateien definieren. Diese Aktion erfolgt über für das Produkt reservierte Symbole. Der Bereich der reservierten Symbole hängt davon ab, wo die Definition erfolgt. Wenn Sie die Berechtigungen in der Datei app.policy definieren, gilt das Symbol für alle Ressourcen in allen Unternehmensanwendungen, die auf dem angegebenen Knoten (Knotenname) ausgeführt werden. Definieren Sie die Berechtigungen in der Datei META-INF/was.policy, gilt das Symbol nur für diese spezifische Unternehmensanwendung. Die folgende Tabelle enthält die gültigen Symbole für die Codebasis:
Tabelle 3. Syntax dynamischer Richtlinien.

In dieser Tabelle sind die gültigen Symbole für die Codebasis für dynamische Richtliniendateien beschrieben.

Symbol Bedeutung
file:${application} Die Berechtigungen gelten für alle Ressourcen in der Anwendung.
file:${jars} Die Berechtigungen gelten für alle JAR-Dateien (Java Archive) von Dienstprogrammen in der Anwendung.
file:${ejbComponent} Berechtigungen gelten für alle EJB-Ressourcen in der Anwendung
file:${webComponent} Die Berechtigungen gelten für Webressourcen in der Anwendung.
file:${connectorComponent} Die Berechtigungen gelten für die Connector-Ressourcen in der Anwendung.
Sie können den Modulnamen für eine differenzierte Einstellung angeben. Ausgenommen sind die Einträge, die mit den Symbolen für die Codebasis angegeben werden. Beispiel:
grant codeBase "file:DefaultWebApplication.war" {
   permission java.security.SecurityPermission "printIdentity";
 };

grant codeBase "file:IncCMP11.jar" {
permission java.io.FilePermission 
"${user.install.root}${/}bin${/}DefaultDB${/}-", 
"read,write,delete";
};
Die sechste und siebte Zeile im vorherigen Codebeispiel sind eine fortlaufende Zeile.Sie können nur in der Datei META-INF/was.policy eine relative Codebasis verwenden.Mehrere für das Produkt reservierte Symbole sind definiert, um Berechtigungslisten einen speziellen Ressourcentyp zuzuordnen.
Tabelle 4. Syntax dynamischer Richtlinien.

In dieser Tabelle sind verschiedene für das Produkt reservierte Symbole beschrieben, die für die Zuordnung der Berechtigungslisten zu einem bestimmten Typ von Ressource definiert werden.

Symbol Bedeutung
file:${application} Die Berechtigungen gelten für alle Ressourcen in der Anwendung.
file:${jars} Berechtigungen gelten für alle JAR-Dateien von Dienstprogrammen in der Anwendung
file:${ejbComponent} Berechtigungen gelten für alle Enterprise-Bean-Ressourcen in der Anwendung
file:${webComponent} Die Berechtigungen gelten für Webressourcen in der Anwendung.
file:${connectorComponent} Die Berechtigungen gelten für die Connector-Ressourcen in der Anwendung und für eigenständige Connector-Ressourcen.
Es werden fünf eingebettete Symbole bereitgestellt, mit denen Sie den Pfad und den Namen für java.io.FilePermission angeben können. Diese Symbole ermöglichen, Berechtigungen flexibel anzugeben. Der absolute Dateipfad wird nach der Installation der Anwendung festgelegt.
Tabelle 5. Syntax dynamischer Richtlinien.

In dieser Tabelle sind die integrierten Symbole beschrieben die bereitgestellt werden, um den Pfad und den Namen für die Berechtigung "java.io.FilePermission" anzugeben.

Symbol Bedeutung
${app.installed.path} Pfad, in dem die Anwendung installiert ist.
${was.module.path} Pfad, in dem das Modul installiert ist.
${current.cell.name} Aktueller Zellenname
${current.node.name} Aktueller Knotenname
${current.server.name} Aktueller Servername
Achtung: ${was.module.path} darf im Eintrag ${application} nicht verwendet werden.

Ermitteln Sie sorgfältig, wo Sie eine neue Berechtigung hinzufügen müssen. Eine fehlerhaft angegebene Berechtigung führt zu einer Ausnahme AccessControlException. Da eine dynamische Richtlinie zur Laufzeit die Codebasis auflöst, ist es schwer herauszufinden, welche Richtliniendatei einen Fehler hat. Fügen Sie nur zu erforderlichen Ressourcen eine Berechtigung hinzu. Verwenden Sie beispielsweise ${ejbcomponent} und etc anstelle von ${application}, und aktualisieren Sie die Datei was.policy anstelle der Datei app.policy.

Statische Richtlinienfilter

Statische Richtlinienfilter werden begrenzt unterstützt. Wenn für die Datei app.policy und für die Datei was.policy in der Datei filter.policy Berechtigungen mit dem Schlüsselwort filterMask definiert sind, entfernt die Laufzeit die Berechtigungen aus den Anwendungen, und es wird eine Prüfnachricht protokolliert. Sollte es sich bei den in den Dateien app.policy und was.policy definierten Berechtigungen jedoch um zusammengesetzte Berechtigungen handeln, wie z. B. java.security.AllPermission, wird die Berechtigung nicht entfernt. Stattdessen wird eine Warnung in die Protokolldatei geschrieben. Die Richtlinienfilter unterstützen nur Developer-Kit-Berechtigungen (hier beginnt der Name des Berechtigungspakets mit java oder javax).

Für die Inkraftsetzung strengerer Filter wird die Unterstützung für Laufzeitrichtlinienfilter bereitgestellt. Falls für die Datei app.policy und die Datei was.policy in der Datei filter.policy Berechtigungen mit dem Schlüsselwort runtimeFilterMask definiert sind, entfernt die Laufzeit die Berechtigungen aus den Anwendungen, unabhängig davon, welche Berechtigungen dieser Anwendung erteilt wurden. Beispiel: Selbst wenn der Datei was.policy die Berechtigung "java.security.AllPermission" für ein in der Datei enthaltenes Modul erteilt wurde, wird eine angegebene Berechtigung, wie z. B. runtimeFilterMask, zur Laufzeit aus der erteilten Berechtigung entfernt.

Richtliniendateien bearbeiten

Mit dem Richtlinientool von Developer Kit (Stammverzeichnis_des_Anwendungsservers/java/jre/bin/policytool) können Sie die früheren Richtliniendateien bearbeiten. Für WebSphere Application Server Network Deployment extrahieren Sie die Richtliniendateien vor dem Editieren aus dem Repository. Nach dem Extrahieren können Sie die Dateien mit dem Richtlinientool editieren. Die geänderten Richtliniendateien müssen in das Repository zurückgegeben und mit den anderen Knoten synchronisiert werden.

Fehlerbehebung

Um Fehler von dynamischen Richtlinien zu beheben, gibt es drei Möglichkeiten, einen ausführlichen Bericht der Ausnahme AccessControlException zu generieren.
  • Trace (durch RAS-Trace konfiguriert). Aktiviert Traces mit der folgenden Tracespezifikation:
    Achtung: Der folgende befehl muss in einer Zeile eingegeben werden:
    com.ibm.ws.security.policy.*=all=enabled:
    com.ibm.ws.security.core.SecurityManager=all=enabled
  • Trace (durch eine Eigenschaft konfiguriert). Gibt eine Java-Eigenschaft "java.security.debug" an. Die gültigen Werte für die Eigenschaft "java.security.debug" sind im Folgenden aufgelistet:
    • Access. Gibt alle Debuginformationen aus: erforderliche Berechtigung, Code, Stack und Position der Codebasis.
    • Stack. Gibt Debuginformationen aus: erforderliche Berechtigung, Code und Stack.
    • Failure. Gibt folgende Debuginformationen aus: erforderliche Berechtigung und Code.
  • ffdc. Aktivieren Sie ffdc und ändern Sie dann in der Datei ffdcRun.properties die Einstellungen Level=4 und LAE=true. Suchen Sie in der Protokolldatei nach dem Schlüsselwort "Access Violation" (unberechtigter Zugriff).

Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_rpolicydir
Dateiname:rsec_rpolicydir.html