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.

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
Richtliniendatei | Position |
---|---|
java.policy |
|
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. |
Dynamische Richtliniendateien
Richtliniendatei | Position |
---|---|
spi.policy | Profilstammverzeichnis/config/cells/Zellenname 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 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 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 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. |
Syntax der Richtliniendatei
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: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. |
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";
};
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. |
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 |
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
- 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).