Java-2-Sicherheit

Die Java-2-Sicherheit bietet ein richtlinienbasiertes, differenziertes Verfahren für die Zugriffssteuerung, das die allgemeine Systemintegrität verstärkt. Es sucht nach Berechtigungen, bevor es den Zugriff auf bestimmte, geschützte Systemressourcen zulässt. Die Java-2-Sicherheit sichert den Zugriff auf Systemressourcen wie Datei-E/A, Sockets und Eigenschaften. Die J2EE-Sicherheit überwacht hingegen den Zugriff auf Webressourcen, wie z. B. Servlets, JSP-Dateien (JavaServer Pages) und EJB-Methoden.

Die Java-2-Sicherheit ist ein relativ neues Konzept und stellt auch für WebSphere eine Neuheit dar. Daher sind viele vorhandene oder sogar neue Anwendungen möglicherweise nicht für das sehr fein unterteilte Programmiermodell für Zugriffssteuerung, das die Java-2-Sicherheit einsetzen kann, bereit. Administratoren müssen sich der möglichen Konsequenzen bewusst sein, die sich ergeben können, wenn die Java-2-Sicherheit aktiviert wird, ohne dass die Anwendungen entsprechend vorbereitet wurden. Die Java-2-Sicherheit legt einige neue Voraussetzungen für Anwendungsentwickler und Administratoren fest.

[IBM i]Wichtig: Die Java-2-Sicherheit gilt nur für Java-Programme, die in einer Java Virtual Machine mit aktivierter Java-2-Sicherheit ausgeführt werden. Systemsystem sind nicht geschützt, wenn die Java-2-Sicherheit inaktiviert ist oder andere Programme oder Befehle auf die Systemressourcen zugreifen. Wenn Sie Ihre Systemressourcen schützen möchten, müssen Sie die Sicherheit des Betriebssystems verwenden.
Fehler vermeiden Fehler vermeiden: Der Anwendungsserver unterstützt keine angepasste Implementierung des Java™-Sicherheitsmanagers.gotcha

Java-2-Sicherheit für Implementierer und Administratoren

Die Java-2-Sicherheit wird zwar unterstützt, ist aber standardmäßig inaktiviert. Sie können die Java-2-Sicherheit und die Verwaltungssicherheit unabhängig voneinander konfigurieren. Beachten Sie außerdem, dass durch das Inaktivieren der Verwaltungssicherheit die Java-2-Sicherheit nicht automatisch inaktiviert wird. Sie müssen die Java 2-Sicherheit explizit inaktivieren.

Wenn die Anwendungen bzw. die Bibliotheken von Fremdanbietern nicht entsprechend vorbereitet wurden, können bei aktivierter Java-2-Sicherheit Fehler auftreten. Diese Probleme sind an den Java-2-Sicherheitsausnahmen des Typs "AccessControlExceptions" in den Systemprotokoll- oder Tracedateien zu erkennen. Wenn Sie nicht sicher sind, ob Ihre Anwendungen für die Java-2-Sicherheit bereit sind, inaktivieren Sie zuerst die Java-2-Sicherheit, installieren Sie die entsprechende Anwendung und prüfen Sie, ob sie ordnungsgemäß funktioniert.

Die Richtlinie, die von diesen Richtliniendateien realisiert wird, kann nicht restriktiver gestaltet werden, da das Produkt möglicherweise nicht die notwendigen doPrivileged-APIs der Java-2-Sicherheit besitzt. Die restriktive Richtlinie ist die Standardrichtlinie. Sie können weitere Berechtigungen erteilen, die Richtlinie kann jedoch nicht restriktiver gestaltet werden, da Ausnahmen des Typs "AccessControlExceptions" in WebSphere Application Server generiert werden. Das Produkt unterstützt keine Richtlinie, die restriktiver ist als die in den zuvor erwähnten Richtliniendateien realisierte Standardrichtlinie.

Es gibt verschiedene Richtliniendateien, die verwendet werden, um die Sicherheitsrichtlinie für den Java-Prozess zu definieren. Diese Richtliniendateien sind statisch (die Codebasis ist in der Richtliniendatei definiert) und entsprechen dem Standardformat für Richtlinien von IBM Developer Kit, Java Technology Edition. Für Unternehmensanwendungsressourcen und Dienstprogrammbibliotheken stellt der WebSphere Application Server eine dynamische Richtlinienunterstützung bereit. Die Codebasis wird basierend auf Implementierungsinformationen dynamisch berechnet, und Berechtigungen werden basierend auf Richtlinienschablonendateien während der Laufzeit erteilt. Weitere Informationen finden Sie im Artikel Richtliniendateien für die Java-2-Sicherheit.

Syntaxfehler in den Richtliniendateien bewirken, dass der Anwendungsserverprozess fehlschlägt. Deshalb müssen diese Richtliniendateien sorgfältig editiert werden.

[IBM i]Anmerkung: Editieren Sie diese Richtliniendateien mit dem zu diesem Zweck von IBM Developer Kit, Java Technology Edition bereitgestellten Richtlinientool. Nähere Informationen finden Sie im Artikel Mit PolicyTool Richtliniendateien für die Java-2-Sicherheit verwenden.

Wenn eine Anwendung nicht für die Java-2-Sicherheit bereit ist, der Anwendungsprovider eine was.policy-Datei nicht als Teil der Anwendung bereitstellt bzw. der Anwendungsprovider die erwarteten Berechtigungen nicht überträgt, ist die Wahrscheinlichkeit hoch, dass die Anwendung zur Laufzeit Ausnahmen der Java-2-Sicherheit, die sich auf die Zugriffssteuerung beziehen, auslöst. Möglicherweise ist nicht klar erkennbar, dass eine Anwendung nicht für die Java-2-Sicherheit bereit ist. Sie können mit verschiedenen Debug-Unterstützungsfunktionen für die Laufzeit Fehler in Anwendungen, in denen Ausnahmen hinsichtlich der Zugriffssteuerung aufgetreten sind, beheben. Weitere Informationen enthält der Abschnitt zur Debugging-Unterstützung der Java-2-Sicherheit. Weitere Informationen und Strategien zur Verwendung solcher Anwendungen finden Sie im Artikel Behandlung von Anwendungen, die nicht für die Java-2-Sicherheit bereit sind.

Wenn die Java-2-Sicherheit in den Einstellungen für die Verwaltungssicherheit aktiviert ist, überprüft der installierte Sicherheitsmanager derzeit nicht die Berechtigungen "modifyThread" und "modifyThreadGroup" für Threads, die keine Systemthreads sind. Einen Thread durch Web- und EJB-Anwendungscode erstellen oder ändern zu lassen, kann negative Auswirkungen auf andere Komponenten des Containers haben und die Fähigkeit des Containers, Lebenszyklen von Enterprise-Beans und Transaktionen zu verwalten, beeinträchtigen.

Java-2-Sicherheit für Anwendungsentwickler

Anwendungsentwickler müssen mit den in der WebSphere-Standardrichtlinie erteilten Berechtigungen sowie den Berechtigungsvoraussetzungen der SDK-APIs, die von deren Anwendung aufgerufen werden, vertraut sein, um feststellen zu können, ob weitere Berechtigungen erforderlich sind. Die Referenz "Berechtigungen im Java 2 SDK" im Abschnitt "Ressourcen" beschreibt, welche APIs welche Berechtigung erfordern.

Anwendungsprovider können annehmen, dass Anwendungen die in der oben genannten Standardrichtlinie erteilten Berechtigungen besitzen. Anwendungen, die auf nicht von der WebSphere-Standardrichtlinie abgedeckte Ressourcen zugreifen, sind erforderlich, um der Anwendung die zusätzlichen Java-2-Sicherheitsberechtigungen zu erteilen.

Sie können der Anwendung zwar zusätzliche Berechtigungen in einer der anderen dynamischen WebSphere-Richtliniendateien oder in einer der traditionellen statischen Richtliniendateien vom Typ java.policy erteilen. Die Datei was.policy, die in der EAR-Datei eingebettet ist, stellt dann aber sicher, dass die zusätzlichen Berechtigungen genau der Anwendung zugeordnet werden, die sie benötigt. Wenn Sie die Berechtigung über den Geltungsbereich des die Berechtigung erfordernden Anwendungscodes hinaus zuweisen möchten, kann der Code möglicherweise auf Ressourcen zugreifen, für die er sonst keine Zugriffsberechtigung hätte.

Bei der Entwicklung einer Anwendungskomponente, wie z. B. einer Bibliothek, die tatsächlich in mehreren .ear-Dateien enthalten ist, sollte der Entwickler die erforderlichen Java 2-Berechtigungen, die vom Anwendungsassemblierer benötigt werden, dokumentieren. Für Komponenten des Typs "Bibliothek" gibt es keine was.policy-Datei. Der Entwickler muss die erforderlichen Berechtigungen anhand der API-Dokumentation oder einer anderen externen Dokumentation übertragen.

Wenn die Komponentenbibliothek von mehreren Unternehmensanwendungen gemeinsam verwendet wird, können die Berechtigungen allen Unternehmensanwendungen auf dem Knoten, der in der Datei app.policy angegeben ist, erteilt 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.

Wenn die Berechtigung nur intern von der Komponentenbibliothek verwendet wird und der Anwendung der Zugriff auf die von der Berechtigung geschützten Ressourcen nie erteilt wird, muss der Code möglicherweise als privileged markiert werden. Weitere Einzelheiten finden Sie im Artikel AccessControlException. Wenn ein doPrivileged-Aufruf nicht ordnungsgemäß eingefügt wird, entstehen möglicherweise Lücken im Sicherheitssystem. Sie müssen also mit doPrivileged-Aufrufen vertraut sein, um entscheiden zu können, ob doPrivileged eingefügt werden soll.

Der Abschnitt über dynamische Richtliniendateien im Artikel Richtliniendateien für die Java-2-Sicherheit beschreibt, wie die Berechtigungen in den was.policy-Dateien zur Laufzeit erteilt werden.

Das Entwickeln einer Anwendung mit der Java-2-Sicherheit ist Neuland und setzt ein Sicherheitsbewusstsein voraus, das bisher von Anwendungsentwicklern nicht erwartet wurde. Die Beschreibung des Java-2-Sicherheitsmodells und seiner Auswirkungen auf die Anwendungsentwicklung geht über den Rahmen dieser Dokumentation hinaus. Unter dem folgenden URL finden Sie ausführliche Informationen: http://java.sun.com/j2se/1.5.0/docs/guide/security/index.html.

Debugging-Unterstützung

Die SYSOUT-Datei von WebSphere Application Server und die Eigenschaft "com.ibm.websphere.java2secman.norethrow" sind die beiden primären Debugging-Hilfen.

WebSphere-Systemprotokoll- und -Tracedateien

Die Ausnahmen des Typs "AccessControl", die in den Systemprotokoll- und Tracedateien aufgezeichnet werden, enthalten Informationen zur Zugriffschutzverletzung, die die Ausnahme ausgelöst hat, den Ausnahmeaufrufstack und die Berechtigungen, die den einzelnen Stack-Rahmen zugewiesen sind. Diese Informationen sind normalerweise ausreichend, um die fehlende Berechtigung sowie den Code, der die Berechtigung erfordert, zu bestimmen.

Eigenschaft "com.ibm.websphere.java2secman.norethrow"

Wenn die Java-2-Sicherheit in WebSphere Application Server aktiviert ist, erstellt der Sicherheitsmanager eine Ausnahme vom Typ "java.security.AccessControl", wenn eine Berechtigungsverletzung erkannt wird. Diese Ausnahme löst, sofern sie nicht behandelt wird, häufig einen Laufzeitfehler aus. Diese Ausnahme wird auch in der SYSOUT-Datei protokolliert.

Wenn jedoch die JVM-Eigenschaft "com.ibm.websphere.java2secman.norethrow" definiert ist und den Wert true hat, erstellt der Sicherheitsmanager keine AccessControl-Ausnahme. Diese Information wird protokolliert.

Diese Eigenschaft ist für eine Sandbox- oder Debugumgebung erst vorgesehen, da es den Sicherheitsmanager anweist, die AccessControl-Ausnahme nicht auszulösen. Die Java 2-Sicherheit wird nicht umgesetzt. Diese Eigenschaft darf nicht in einer Produktionsumgebung verwendet werden, in der eine gelockerte Java-2-Sicherheitsumgebung genau die Integrität schwächt, die sie ja erst herstellen soll.

Diese Eigenschaft ist wertvoll in einer Sandbox- oder Testumgebung, in der die Anwendung gründlich getestet und die Systemprotokoll- und Tracedateien auf Ausnahmen des Typs "AccessControl" untersucht werden kann. Da diese Eigenschaft die AccessControl-Ausnahme nicht auslöst, wird der Aufruf-Stack nicht weitergegeben und kein Fehler ausgelöst. Ohne diese Eigenschaft müssen Sie AccessControl-Ausnahmen nacheinander ermitteln und beheben.

Behandlung von Anwendungen, die nicht für die Java-2-Sicherheit bereit sind

Wenn die von der Java-2-Sicherheit bereitgestellte erhöhte Systemintegrität für Sie wichtig ist, wenden Sie sich an den Anwendungsprovider, um die Unterstützung der Java-2-Sicherheit durch die Anwendungsunterstützung sicherzustellen, oder teilen Sie ihm zumindest die erforderlichen zusätzlichen Berechtigungen, die über die Standardrichtlinie von WebSphere Application Server hinaus erteilt werden müssen, mit.

Die einfachste Vorgehensweise bei diesen Anwendungen ist die Inaktivierung der Java-2-Sicherheit in WebSphere Application Server. Der Nachteil ist, dass diese Lösung für das gesamte System gilt und die Integrität des Systems nicht so stark ist wie sie tatsächlich sein könnte. Das Inaktivieren der Java-2-Sicherheit ist je nach Sicherheitsstrategie oder Risikobereitschaft der Organisation unter Umständen keine akzeptable Lösung.

Eine andere Möglichkeit ist, die Java-2-Sicherheit aktiviert zu lassen, der entsprechenden Anwendung jedoch lediglich ausreichende Berechtigungen bzw. alle Berechtigungen zu erteilen. Die Berechtigungen zu erteilen, kann jedoch ein komplexer Vorgang sein. Wenn der Anwendungsprovider die erforderlichen Berechtigungen nicht auf irgendeine Art mitgeteilt hat, ist es schwierig, festzustellen, welche Berechtigungen erforderlich sind. In diesem Fall ist die Erteilung aller Berechtigungen möglicherweise der einzig gangbare Weg. Dieses Risiko können Sie dadurch verringern, dass Sie eine solche Anwendung auf einem anderen Knoten installieren und sie dadurch von bestimmten Ressourcen isolieren. Sie können die Berechtigung "java.security.AllPermission" in der Datei was.policy, die in der .ear-Datei eingebettet ist, erteilen. Beispiel:
grant codeBase "file:${application}" {
            permission java.security.AllPermission;
        };

Datei "server.policy"

[AIX Solaris HP-UX Linux Windows][z/OS]Die Datei server.policy befindet sich im Verzeichnis Stammverzeichnis_des_Anwendungsservers/properties/.

[IBM i]Die Datei server.policy befindet sich im Verzeichnis Profilstammverzeichnis/properties.

Diese Richtlinie definiert die Richtlinie für die Klassen von WebSphere Application Server. Derzeit verwenden alle Serverprozesse in einer Installation dieselbe server.policy-Datei. Sie können diese Datei jedoch so konfigurieren, dass jeder Serverprozess eine separate Datei server.policy erhält. Definieren Sie die Richtliniendatei als Wert der Java-Systemeigenschaften "java.security.policy". Ausführliche Informationen zur Definition der Java-Systemeigenschaften enthält der Abschnitt "Prozessdefinition" unter "Anwendungsserver verwalten".

Die Datei server.policy ist keine Konfigurationsdatei, die vom Repository und vom Dateireplikationsservice verwaltet wird. Änderungen an dieser Datei sind lokal und werden nicht auf anderen Maschinen repliziert. Die Datei server.policy muss zum Definieren der Java 2-Sicherheitsrichtlinie für Serverressourcen verwendet werden. Verwenden Sie die Datei app.policy (pro Knoten) oder was.policy (pro Unternehmensanwendung), um die Java 2-Sicherheitsrichtlinie für die Ressourcen von Unternehmensanwendungen zu definieren.
Anmerkung: Aktualisierungen der Datei app.policy gelten nur für Unternehmensanwendungen, die auf dem Knoten ausgeführt werden, zu dem die Datei "app.policy" gehört.

Datei "java.policy"

Die Datei enthält die Standardberechtigungen, die allen Klassen erteilt werden. Die Richtlinie dieser Datei gilt für alle Prozesse, die von der Java Virtual Machine (JVM) in WebSphere Application Server gestartet werden.

[AIX Solaris HP-UX Linux Windows][z/OS]Die Datei java.policy befindet sich im Verzeichnis Stammverzeichnis_des_Anwendungsservers/java/lib/security.

[IBM i]Die Datei java.policy befindet sich im Verzeichnis ${java.home}/lib/security/. Hierbei steht ${java.home} für den Pfad des Software Development Kit (SDK), das Sie verwenden. Die Richtliniendatei wird für das gesamte Betriebssystem verwendet. Editieren Sie die Datei java.policy nicht.

Fehlerbehebung

Fehlernachricht CWSCJ0314E

Symptom:

Fehlernachricht CWSCJ0314E: Die aktuelle Java-2-Sicherheitsrichtlinie hat eine potenzielle Zugriffsschutzverletzung in Bezug auf die Java-2-Sicherheitsberechtigungen gemeldet. Weitere Informationen hierzu finden Sie im Handbuch zur Fehlerbestimmung. 0}Berechtigung\:{1}Code\:{2}{3}Stack-Trace\:{4}Position der Codebasis\:{5} Die aktuelle Java 2-Sicherheitsrichtlinie hat eine potenzielle Zugriffsschutzverletzung in Bezug auf die Java 2-Sicherheitsberechtigungen gemeldet. Weitere Informationen hierzu finden Sie im Handbuch zur Fehlerbestimmung. {0}Berechtigung\:{1}Code\:{2}{3}Stack-Trace\:{4}Position der Codebasis\:{5}

Problem:

Die Methode "checkPermission" des Java-Sicherheitsmanagers hat eine Sicherheitsausnahme mit Debugging-Informationen für die untergeordnete Berechtigung aufgezeichnet. Die aufgezeichneten Informationen können je nach Systemkonfiguration variieren. Dieser Bericht wird aktiviert, wenn Sie den RAS-Trace (Reliability Availability Service Ability) im Debug-Modus konfigurieren oder eine Java-Eigenschaft angeben.

Informationen zum Konfigurieren des RAS-Trace im Debug-Modus finden Sie im Artikel Trace aktivieren.

Geben Sie die folgende Eigenschaft in der Anzeige "JVM-Einstellungen" in der Administrationskonsole an: java.security.debug. Gültige Werte:
access
Gibt alle Debug-Informationen aus: erforderliche Berechtigung, Code, Stack und Position der Codebasis.
stack
Gibt folgende Debug-Informationen aus: erforderliche Berechtigung, Code und Stack.
failure
Gibt folgende Debug-Informationen aus: erforderliche Berechtigung und Code.

Empfohlene Maßnahme:

Die aufgezeichnete Ausnahme kann für das geschützte System kritisch sein. Aktivieren Sie den Sicherheitstrace, um den Code zu ermitteln, der möglicherweise die Sicherheitsrichtlinie verletzt hat. Wenn der Code, der die Verletzung ausgelöst hat, ermittelt wurde, müssen Sie überprüfen, ob die beabsichtigte Operation hinsichtlich der Java-2-Sicherheit zulässig ist. Dazu müssen Sie alle verfügbaren Richtliniendateien der Java-2-Sicherheit und den Anwendungscode selbst untersuchen.

Wird die Anwendung mit Java Mail ausgeführt, zeigt diese Nachricht möglicherweise keinen Fehler an. Sie können die Datei was.policy dahingehend aktualisieren, dass der Anwendung die folgenden Berechtigungen erteilt werden:

permission java.io.FilePermission "${user.home}${/}.mailcap", "read";
permission java.io.FilePermission "${user.home}${/}.mime.types", "read";
permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read";
permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";

SecurityException - Access denied

Symptom:

Ist die Java-Sicherheit aktiviert und liegt keine Leseberechtigung für die Datei "jaxm.properties" vor, wenn eine SOAPFactory-Instanz über einen Aufruf von javax.xml.soap.SOAPFactory.newInstance() oder eine MessageFactoray-Instanz durch einen Aufruf von MessageFactory.newInstance() erstellt wird, tritt eine Ausnahme vom Typ SecurityException ein und die folgende Ausnahme wird in das Systemprotokoll geschrieben:
Permission:

      /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties : access denied 
(java.io.FilePermission /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties
read)

Code: 

     com.ibm.ws.wsfvt.test.binding.addr1.binder.AddressBinder  
in  {file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/
ahp6405Node01Cell/DataBinding.ear/address1.war/WEB-INF/lib
/addressbinder1.jar}

Stack Trace: 

java.security.AccessControlException: access denied (java.io.FilePermission 
/opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties read)
.

Problem:

Die aktuelle Java-2-Sicherheitsrichtlinie hat eine potenzielle Zugriffsschutzverletzung in Bezug auf die Java-2-Sicherheitsberechtigungen gemeldet.

Empfohlene Maßnahme:

Die SOAPFactory ignoriert die Ausnahme und fährt mit der nächsten Methode zur Feststellung der zu ladenden Implementierung fort. Daher können Sie den Protokolleintrag für diese Sicherheitsausnahme ignorieren.

Da dieses Produkt die SOAPFactory verwendet, um andere Web-Service-Technologien, wie z. B. WS-Addressing (WS-A), WS-Atomic Transaction (WS-AT) und WS-Notification, zu unterstützen, können Sie diese SecurityException in allen Web-Service-Anwendungen, in denen die Java-Sicherheit aktiviert ist, ignorieren.

Nachrichten

Nachricht: CWSCJ0313E: Die Flags für die Debug-Nachrichten des Java 2-Sicherheitsmanagers werden initialisiert: TrDebug: {0}, Zugriff: {1}, Stack: {2}, Fehler: {3}

Problem: Konfigurierte Werte der gültigen Debug-Nachrichten-Flags für den Sicherheitsmanager.

Nachricht: CWSCJ0307E: Beim Versuch, die Position der Codebasis zu ermitteln, wurde eine unerwartete Ausnahme abgefangen. Ausnahme: {0}

Problem: Beim Versuch, die Position der Codebasis zu ermitteln, wurde eine unerwartete Ausnahme abgefangen.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



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