Sécurité Java 2
La sécurité Java™ 2 fournit un mécanisme de contrôle d'accès très précis, à base de règles, qui accroît l'intégrité du système en vérifiant les droits d'accès avant d'autoriser l'accès à certaines ressources protégées du système. La sécurité Java 2 contrôle l'accès aux ressources du systèmes telles que les E/S de fichier, les sockets et les propriétés. La sécurité J2EE (Java 2 Platform, Enterprise Edition) surveille l'accès aux ressources Web, telles que les servlets, les pages JavaServer (JSP) et les méthodes d'EJB (Enterprise JavaBeans).
La sécurité Java 2 étant une norme relativement récente, de nombreuses applications nouvelles ou existantes peuvent ne pas être compatibles avec le modèle de programmation du contrôle d'accès très précis que la sécurité Java 2 peut appliquer. Les administrateurs doivent comprendre les conséquences possibles de l'activation de la sécurité Java 2 si les applications ne sont pas compatibles avec la sécurité Java 2. La sécurité Java 2 impose de nouvelles conditions aux administrateurs et développeurs d'applications.
![[IBM i]](../images/iseries.gif)

Sécurité Java 2 pour les déployeurs et les administrateurs
Bien que la sécurité Java 2 soit prise en charge, elle est désactivée par défaut. Vous pouvez configurer séparément la sécurité Java 2 et la sécurité administrative. La désactivation de la sécurité administrative n'entraîne pas automatiquement la désactivation de la sécurité Java 2. Vous devez la désactiver explicitement.
Si vos applications ou vos bibliothèques tierces ne sont pas prêtes, l'activation de la sécurité Java 2 risque de générer des erreurs. Ces erreurs apparaissent sous la forme d'exceptions AccessControlExceptions de la sécurité Java 2 dans le fichier journal du système ou les journaux de trace. Si vous n'êtes pas sûr que vos applications sont compatibles avec la sécurité Java 2, désactivez au préalable la sécurité Java 2 pour installer l'application et vérifiez qu'elle fonctionne correctement.
Les stratégies incorporées dans ces fichiers de règles ne peuvent pas devenir plus restrictives car le produit risque de ne pas disposer des API doPrivileged nécessaires de la sécurité Java 2. La stratégie restrictive représente la stratégie par défaut. Vous pouvez accorder des droits supplémentaires mais elle ne peut pas être plus restrictive car les exceptions AccessControlException sont générées dans WebSphere Application Server. Le produit ne prend pas en charge de règles plus restrictives que les stratégies par défaut définies dans les fichiers de règles mentionnés plus haut.
Plusieurs fichiers de règles sont utilisés pour définir les stratégies de sécurité du processus Java. Ces fichiers de règles sont statiques (codeBase défini dans le fichier de règles) et sont au format de règles par défaut fourni par IBM® Developer Kit, Java Technology Edition. Pour les applications d'entreprise, les bibliothèques de ressources et d'utilitaires, WebSphere Application Server prend en charge les stratégies dynamiques. Les valeurs codebase sont calculées de manière dynamique en fonction des informations de déploiement et les droits d'accès sont accordés lors de l'exécution en fonction des modèles de fichiers de règles. Voir Fichiers de règles de sécurité Java 2 pour plus d'informations.
Les erreurs de syntaxe dans les fichiers de règles entraînant l'échec du serveur d'applications, veuillez modifier ces fichiers avec précaution.
![[IBM i]](../images/iseries.gif)
Si une application n'est pas compatible avec Java 2 Security, si le fournisseur d'applications ne livre pas de fichier was.policy avec l'application ou s'il ne communique pas les droits requis, des exceptions de contrôle d'accès Java 2 Security risquent d'être générées lors de l'exécution. Il n'est pas toujours aisé de savoir si une application est compatible Java 2 Security. Plusieurs outils d'aide au débogage de l'environnement d'exécution permettent d'identifier les applications de traitement des incidents dans lesquelles des exceptions de contrôle d'accès liées à Java 2 Security peuvent être générées. Pour plus de détails, reportez-vous à la section Outils d'aide au débogage de la sécurité Java 2. Voir Traitement des applications non compatibles avec la sécurité Java 2 pour des informations et des stratégies applicables à de telles applications.
Il est important de noter que, lorsque Java security est activée dans les paramètres de sécurité administrative, le gestionnaire de sécurité installé ne vérifie pas les droits d'accès modifyThread et modifyThreadGroup des unités d'exécution non système. Autoriser le code d'application Web et EJB (Enterprise JavaBeans) à créer ou modifier une unité d'exécution peut entraîner des répercussions négatives sur d'autres composants du conteneur et risque de nuire aux capacités de ce dernier à gérer les cycles de vie et transactions des beans entreprise.
Sécurité Java 2 pour les développeurs d'applications
Les développeurs d'application doivent connaître le droit accordé dans la stratégie WebSphere par défaut et les droits requis par les API SDK appelées par leurs applications afin de savoir si des droits supplémentaires sont nécessaires. La référence aux droits dans Java 2 SDK de la section relative aux ressources décrit les droits requis pour chaque API .
Les fournisseurs d'applications peuvent considérer que les applications disposent des droits accordés par la stratégie par défaut précédemment mentionnée. Les applications qui accèdent aux ressources non couvertes par la stratégie WebSphere par défaut doivent accorder des droits de sécurité Java 2 supplémentaires à l'application.
Alors qu'il est possible d'accorder des droits supplémentaires à l'application dans les autres fichiers de règles WebSphere dynamiques, ou dans un des fichiers de stratégie statique plus traditionnels tels que java.policy, le fichier was.policy (intégré dans le fichier EAR) garantit que des droits supplémentaires sont sectorisés à l'application qui les requiert. La sectorisation du droit au delà du code d'application nécessitant ce droit peut permettre au code d'accéder à des ressources particulières.
Si un composant d'une application est développé (une bibliothèque, par exemple) et qu'il peut être inclus dans plus d'un fichier .ear, alors le développeur de la bibliothèque doit documenter les droits Java 2 nécessaires à l'assembleur de l'application. Il n'existe pas de fichier was.policy pour les composants de type bibliothèque. Le développeur doit communiquer les droits requis via la documentation de l'API ou une autre documentation externe.
Si le droit est utilisé uniquement de manière interne par la bibliothèque des composants et que l'application ne dispose jamais du droit d'accès aux ressources protégées par ce droit, il peut alors être nécessaire de marquer le code comme étant privilégié. Pour plus de détails, voir l'article Exception liée au contrôle d'accès. Toutefois, l'insertion incorrecte d'un appel doPrivileged peut provoquer des brèches dans la sécurité. Veillez à bien comprendre les conséquences d'un appel doPrivileged pour définir s'il est nécessaire ou non d'insérer un élément de ce type.
La section relative aux fichiers de règles dynamiques dans Fichiers de règles de sécurité Java 2 décrit comment les droits des fichiers was.policy sont accordés lors de l'exécution.
Le développement d'une application à utiliser avec Java 2 Security nécessite de la part des développeurs d'applications de nouvelles compétences et un respect des stratégies de sécurité non requis auparavant. La description du modèle Java 2 Security et ses répercutions sur le développement d'applications ne sont pas abordées dans cette section. L'URL suivante vous guide pour le démarrage : http://java.sun.com/j2se/1.5.0/docs/guide/security/index.html.
Aides au débogage
Le fichier SYSOUT de WebSphere Application Server et la propriété com.ibm.websphere.java2secman.norethrow constituent les deux premières aides pour le débogage.Journal ou fichiers de trace du système WebSphere
L'exception AccessControl consignée dans le journal ou les fichiers de trace du système contient le non-respect du droit qui a provoqué l'exception, la pile d'appels de l'exception et le droit accordé à chaque cadre de pile. Ces informations suffisent généralement à déterminer le droit manquant et le code nécessitant le droit.Propriété com.ibm.websphere.java2secman.norethrow
Lorsque la sécurité Java 2 est activée dans WebSphere Application Server, le gestionnaire de sécurité émet par défaut une exception java.security.AccessControl en cas de non-respect d'un droit. Cette exception, si elle n'est pas gérée, provoque souvent une erreur d'exécution. Cette exception est également consignée dans le fichier SYSOUT.Toutefois, lorsque la propriété com.ibm.websphere.java2secman.norethrow de la machine virtuelle Java Java est définie et que sa valeur est true, le gestionnaire de sécurité n'émet pas d'exception AccessControl. L'information est uniquement consignée.
Cette propriété est conçue pour un bac à sable ou pour un environnement de débogage car elle indique au gestionnaire de sécurité de ne pas émettre d'exception AccessControl. La sécurité Java 2 n'est pas appliquée. Cette propriété ne doit pas être utilisée dans un environnement de production où un environnement de sécurité Java 2 non fiable affaiblit la sécurité Java 2 devant être générée.
Cette propriété n'est fiable que dans un environnement de bac à sable ou de test où l'application peut être minutieusement testée et les exceptions AccessControl peuvent être détectées dans le journal ou les fichiers de trace du système. Etant donné que cette propriété empêche l'émission de l'exception AccessControl, elle ne sera pas propagée dans la pile d'appels et ne provoquera pas d'erreur. Sans cette propriété, les exceptions AccessControl doivent être détectées et résolue individuellement.
Traitement des applications non compatibles avec la sécurité Java 2
Si l'intégrité accrue du système fournie par la sécurité Java 2 est pour vous primordiale, adressez-vous au fournisseur de l'application pour obtenir de l'aide de la part du support technique de la sécurité Java 2 ou communiquez au moins les droits supplémentaires requis en dehors des stratégies WebSphere Application Server par défaut qui doivent être accordés.Avec de telles applications, le plus simple reste de désactiver la sécurité Java 2 dans WebSphere Application Server. Cependant, cette solution s'applique à l'ensemble du système et l'intégrité de ce dernier n'est alors pas aussi forte qu'elle devrait l'être. Il se peut que la désactivation de la sécurité Java ne soit pas acceptable, en fonction des stratégies sécuritaires et des tolérances de risques de l'entreprise.
grant codeBase "file:${application}" {
permission java.security.AllPermission;
};
Fichier server.policy
Le fichier server.policy se trouve dans le répertoire racine_serveur_app/properties/.
Le fichier server.policy se trouve dans le
répertoire racine_profil/properties.
Définit les stratégies des classes WebSphere Application Server. A présent, tous les processus serveur de la même installation partagent le même fichier server.policy. Cependant, vous pouvez configurer ce fichier de telle sorte que chaque processus serveur dispose de son propre fichier server.policy. Définissez le fichier de règles souhaité comme valeur des propriétés système Java java.security.policy. Pour plus de détails sur le mode de définition des propriétés système Java, reportez-vous à la section Définition des processus de la gestion des serveurs d'applications.
Fichier java.policy
Ce fichier contient les droits d'accès par défaut octroyés à toutes les classes. Les stratégies de ce fichier s'appliquent à tous les processus lancés par la machine JVM (Java Virtual Machine) de WebSphere Application Server.
Le fichierjava.policy se trouve dans le
répertoire racine_serveur_app/java/lib/security.
Le fichier java.policy se trouve dans le répertoire ${java.home}/lib/security/
où ${java.home} est le chemin d'accès au Software Development Kit (SDK)
que vous utilisez.
Le fichier de règles est utilisé dans tout le système d'exploitation. N'éditez pas le
fichier java.policy.
Traitement des incidents
- Message d'erreur CWSCJ0314E
Symptôme :
Message d'erreur CWSCJ0314E : La stratégie de sécurité Java 2 actuelle a signalé une violation potentielle des droits d'accès à Java 2. Pour plus d'informations, reportez-vous au guide d'identification des incidents.{0}Droits: {1}Code\:{2}{3}Trace de pile\:{4}Emplacement de base du code\:{5} La stratégie de sécurité Current Java 2 a signalé une violation potentielle des droits d'accès Java 2. Pour plus d'informations, reportez-vous au guide d'identification des incidents. {0}Droits d'accès\:{1}Code\:{2}{3}Trace de la pile\:{4}Emplacement du code\:{5}
Incident :
La méthode checkPermission du gestionnaire de sécurité Java a signalé une exception de sécurité sur les droits concernés et fourni des informations de débogage. Ces informations peuvent différer suivant la configuration du système. Ce rapport est activé en configurant la trace RAS (Reliability Availability Service Ability) en mode débogage ou en indiquant une propriété Java.
Pour plus d'informations sur la configuration du traçage RAS en mode débogage, voir Activation du traçage.
Spécifiez la propriété suivante dans le panneau Paramètres JVM, à l'aide de la console d'administration : java.security.debug. Les valeurs valides sont les suivantes :- access
- Imprimez toutes les informations de débogage, y compris : autorisation requise, code, pile et emplacement du code.
- stack
- Imprimez les informations de débogage, y compris : autorisation requise, code et pile.
- échec
- Imprimez les informations de débogage, y compris : autorisation requise et code.
Solution recommandée :
L'exception signalée peut être critique pour le système sécurisé. Activez le traçage de la sécurité pour déterminer le code ayant éventuellement violé la stratégie de sécurité. Une fois le code fautif détecté, vérifiez si l'opération tentée est autorisée par la sécurité Java 2 en examinant tous les fichiers de règles de sécurité Java 2 applicables ainsi que le code d'application.
Si l'application s'exécute avec Java Mail, ce message est probablement bénin. Vous pouvez mettre à jour le fichier was.policy pour accorder à l'application les droits suivants :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 - Accès refusé
Symptôme :
Si la sécurité Java est activée, et les autorisations permettant de lire de fichier jaxm.properties n'ont pas été accordées, une exception SecurityException survient lorsqu'une instance SOAPFactory est créée par un appel à javax.xml.soap.SOAPFactory.newInstance(), ou une instance MessageFactory et créée par un appel à MessageFactory.newInstance(), et l'exception suivante est enregistrée dans le journal système :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) .
Incident :
La stratégie de sécurité Java 2 signale une violation potentielle des droits d'accès à Java 2.
Solution recommandée :
SOAPFactory ignore l'exception et passe au moyen suivant de déterminer l'implémentaton à charger. Vous pouvez donc ignorer l'entrée du journal pour cette exception de sécurité.
Etant donné que ce produit utilise SOAPFactory pour prendre en charge les technologies de services Web, telles que WS-Addressing (WS-A), WS-Atomic Transaction (WS-AT) et WS-Notification, vous pouvez ignorer cette exception de sécurité dans l'application des services Web dans laquelle la sécurité Java est activée.
Messages
Message : CWSCJ0313E: Les indicateurs des messages de débogage de Java 2 Security Manager sont initialisés \\: TrDebug : {0}, Access : {1}, Stack : {2}, Failure : {3}
Problème : Valeurs configurées des indicateurs des messages de débogage valides pour le gestionnaire de sécurité.
Message : CWSCJ0307E: Exception inattendue générée lors de la tentative de détermination de l'emplacement de base du code. Exception : {0}
Problème : Exception inattendue générée lors de la détermination de l'emplacement de base du code.