Fichiers de règles de sécurité Java 2

Les spécifications J2EE (Java™ 2 Platform, Enterprise Edition) version 1.3 et ultérieure comportent un modèle de programmation précis des responsabilités des fournisseurs de conteneurs et du code d'application. Il est recommandé d'utiliser le gestionnaire de sécurité Java 2 pour faciliter l'application de ce modèle de programmation. Certaines opérations ne sont pas autorisées dans le code d'application car elles ont une incidence sur le comportement et le fonctionnement des conteneurs. Le gestionnaire de sécurité Java 2 est utilisé dans le produit pour appliquer les responsabilités du conteneur et du code d'application.

Eviter les incidents Eviter les incidents: Le serveur d'applications ne prend pas en charge l'implémentation d'un gestionnaire de sécurité Java personnaliségotcha

Le produit WebSphere fournit le support pour la gestion du fichier de règles. Un certain nombre de fichiers de règles dans ce produit sont statiques ou dynamiques. La règle dynamique est un modèle de droits d'accès pour un type particulier de ressource. Aucune base de code relative n'est définie dans le modèle de règles dynamique. Cette valeur est calculée de manière dynamique à partir des données de déploiement et d'exécution.

fichiers de règles statiques

Tableau 1. fichiers de règles statiques.

Ce tableau répertorie l'emplacement des fichiers de règles statiques.

Fichier de règles Emplacement
java.policy

[AIX Solaris HP-UX Linux Windows][z/OS]racine_serveur_app/java/jre/lib/security/java.policy. Des droits d'accès par défaut sont octroyés à toutes les classes. Les règles de ce fichier s'appliquent à tous les processus lancés par WebSphere Application Server.

server.policy profile_root/properties/server.policy. Des droits d'accès par défaut sont octroyés à tous les serveurs du produit.
client.policy racine_profil/properties/client.policy. Des droits d'accès par défaut sont octroyés pour tous les conteneurs client et les applets sur un noeud.
Les fichiers de règles statiques ne sont pas gérés par des services de réplication ou de configuration. Les modifications apportées à ces fichiers sont locales et ne sont pas répliquées sur d'autres noeuds dans la cellule WebSphere Application Server, Network Deployment.

fichiers de règles dynamiques

Tableau 2. fichiers de règles dynamiques.

Ce tableau répertorie l'emplacement des fichiers de règles dynamiques.

Fichier de règles Emplacement
spi.policy

racine_profil/config/cells/nom_cellule
/nodes/nom_noeud/spi.policy

Ce modèle s'applique à l'interface SPI (Service Provider Interface) ou à des ressources imbriquées dans le produit. Exemples de SPI : Java Message Service (JMS) dans MQ Series et pilotes JDBC (Java database connectivity). Le base de code des ressources imbriquées est défini de manière dynamique à partir des données de configuration (fichier resources.xml) et d'exécution et les droits d'accès définis dans les fichiers spi.policy sont automatiquement appliqués à ces ressources et aux fichiers JAR indiqués dans le chemin d'accès aux classes d'un adaptateur de ressources. Les droits d'accès par défaut de spi.policy correspondent à java.security.AllPermissions.

library.policy

racine_profil/config/cells/nom_cellule/nodes
/nom_noeud/library.policy

Ce modèle s'applique à la bibliothèque (classes de bibliothèque Java ). Vous pouvez définir une bibliothèque partagée à utiliser dans plusieurs applications du produit. Le droit d'accès par défaut du fichier library.policy est vide.

app.policy

racine_profil/config/cells/nom_cellule
/nodes/nom_noeud/app.policy

Le fichier app.policy définit les droits d'accès par défaut octroyés à toutes les applications d'entreprise s'exécutant sur nom_noeud dans nom_cellule.
Remarque : Les mises à jour apportées au fichier app.policy s'appliquent uniquement aux applications d'entreprise sur le noeud auquel le fichier app.policy appartient.
was.policy

racine_profil/config/cells/nom_cellule
/applications/nom_fichier_ear/deployments/
nom_application/META-INF/was.policy

Ce modèle s'applique aux droits d'accès propres à l'application. Le fichier was.policy est imbriqué dans le fichier EAR (enterprise archive).

ra.xml nom_fichier_ear/META-INF/was.policy.RAR.

Ce fichier possède une spécification des droits d'accès définie dans le fichier ra.xml. Le fichier ra.xml est imbriqué dans le fichier RAR.

Une base de code doit être définie pour les entrées d'octroi spécifiées dans les fichiers app.policy et was.policy. S'il existe des entrées d'octroi spécifiées sans base de code, les fichiers de règles ne se chargent pas correctement et l'application risque de d'échouer. Si votre intention consiste à octroyer les droits d'accès à toutes les applications, utilisez file:${application} comme base de code dans l'entrée d'octroi.

Syntaxe du fichier de règles

Un fichier de règles contient plusieurs règles. L'exemple ci-après présente le format de chaque règle :
grant [codebase <Codebase>] {
permission <Permission>;
 permission <Permission>;
permission <Permission>;
};

<CodeBase>: 	A URL.
			Par exemple,  "fichier ${java.home}/lib/tools.jar"
						Lorsque [codebase <Codebase>] n'est pas défini, les 
               les droits figurant dans la liste sont appliqués à tous les objets.
						Si l'adresse URL se termine par un nom de fichier JAR,
seules les classes du fichier JAR font partie de la base de code
(codebase).
               Si l'URL se termine par le caractère "/", seuls les fichiers de
classe dans le répertoire indiqué appartiennent à la base de code
(codebase).
               Si l'URL se termine par le caractère "*", tous les fichiers de
classe dans le répertoire indiqué appartiennent à la base de code
(codebase).
               Si l'URL se termine par le caractère "-", tous les fichiers JAR et de
classe dans le répertoire 
               indiqué et dans les sous-répertoires
associés appartiennent à la base du code.
<Permissions> : constitué de
							Type de droit  	: nom de classe du droit d'accès
     					Nom cible      	: nom indiquant la cible
     					Actions        	: actions autorisées sur la cible
			Par exemple,
      			java.io.FilePermission "/tmp/xxx", "read,write"
Reportez-vous aux spécification SDK pour en savoir plus sur chaque droit d'accès.

Syntaxe de règles dynamique

Vous pouvez définir les droits d'accès pour des types de ressources spécifiques dans des fichiers de règles dynamiques d'une application d'entreprise. Cette action est effectuée à l'aide de symboles réservés propres au produit. La portée des symboles réservés varie en fonction du fichier dans lequel ils sont définis. Si vous définissez les droits d'accès dans le fichier app.policy, le symbole s'applique à toutes les ressources de toutes les applications d'entreprise exécutées sur nom_noeud. Si vous définissez les droits d'accès dans le fichier META-INF/was.policy, le symbole s'applique uniquement à l'application d'entreprise indiquée. Les symboles valides pour la base de code sont répertoriés dans le tableau ci-après :
Tableau 3. Syntaxe de règles dynamiques.

Ce tableau répertorie les symboles valides pour le codebase des fichiers de règles dynamiques.

Symbole Signification
file:${application} Les droits d'accès s'appliquent à toutes les ressources dans l'application.
file:${jars} Les droits d'accès s'appliquent à tous les fichiers JAR (Java archive) utilitaires de l'application
file:${ejbComponent} Les droits d'accès s'appliquent aux ressources EJB (JavaBeans) de l'application
file:${webComponent} Les droits d'accès s'appliquent aux ressources Web dans l'application.
file:${connectorComponent} Les droits d'accès s'appliquent aux ressources du connecteur dans l'application.
Vous pouvez indiquer le nom du module pour un paramètre granulaire, sauf pour les entrées précisées par les symboles de base de code. par exemple :
grant codeBase "file:DefaultWebApplication.war" {
   permission java.security.SecurityPermission "printIdentity";
 };

grant codeBase "file:IncCMP11.jar" {
permission java.io.FilePermission 
"${racine.install.utilisateur}${/}bin${/}DefaultDB${/}-", 
"read,write,delete";
};
Les sixième et septième lignes de l'exemple de code précédent doivent être sur une même ligne. Vous ne pouvez utiliser un code relatif que dans le fichier META-INF/was.policy. Plusieurs symboles réservés sont définis pour associer les listes de droits d'accès à un type de ressource spécifique.
Tableau 4. Syntaxe de règles dynamiques.

Ce tableau répertorie et décrit divers symboles réservés au produit définis pour associer les listes d'autorisations à un type de ressource.

Symbole Signification
file:${application} Les droits d'accès s'appliquent à toutes les ressources dans l'application.
file:${jars} Les droits d'accès s'appliquent à tous les fichiers JAR d'utilitaire dans l'application.
file:${ejbComponent} Les droits d'accès s'appliquent aux ressources des beans enterprise dans l'application.
file:${webComponent} Les droits d'accès s'appliquent aux ressources Web dans l'application.
file:${connectorComponent} Les droits d'accès s'appliquent aux ressources de connecteur, qu'elles soient dans l'application ou autonomes.
Cinq symboles imbriqués sont fournis pour indiquer le chemin d'accès et le nom de java.io.FilePermission. Ces symboles permettent une spécification de droits d'accès souple. Le chemin d'accès absolu reste identique une fois l'application installée.
Tableau 5. Syntaxe de règles dynamiques.

Ce tableau répertoire et décrit les symboles intégrés fournis pour indiquer le chemin d'accès et le nom de l'autorisation java.io.FilePermission.

Symbole Signification
${app.installed.path} Chemin d'accès à l'emplacement de l'installation de l'application.
${was.module.path} Chemin d'accès à l'emplacement d'installation du module.
${current.cell.name} Nom de cellule actuel
${current.node.name} Nom de noeud actuel
${current.server.name} Nom de serveur actuel
Avertissement : N'utilisez pas ${was.module.path} dans l'entrée ${application}.

Déterminez minutieusement où vous devez ajouter le nouveau droit d'accès. Si vous définissez un droit d'accès de manière incorrecte, l'exception AccessControlException est générée. Etant donné que les règles dynamiques résolvent la base de code lors de l'exécution, il est difficile de déterminer le fichier de règles présentant un problème. Ajoutez un droit d'accès uniquement aux ressources nécessaires. Par exemple, dans la mesure du possible, utilisez ${ejbcomponent} et etc au lieu de ${application} et mettez à jour le fichier was.policy au lieu du fichier app.policy.

Filtrage de la règle statique

Un filtrage restreint de la règle statique est possible. Si les droits d'accès des fichiers app.policy et was.policy ont été définis dans le fichier filter.policy avec le mot clé thefilterMask, le module d'exécution supprime ces droits des applications et un message d'audit est consigné. Toutefois, si les droits définis dans les fichiers app.policy et was.policy correspondent à des droits composés, par exemple java.security.AllPermission, le droit n'est pas supprimé mais un message d'avertissement est consigné dans le fichier journal. Le filtrage des règles prend uniquement en charge ceux de JDK et le nom du package des droits d'accès commence par java ou javax.

Le filtrage des stratégies de l'environnement d'exécution est pris en charge pour renforcer le filtrage. Si les droits d'accès des fichiers app.policy et was.policy sont définis dans le fichier filter.policy avec le mot clé runtimeFilterMask, le module d'exécution supprime les droits d'accès des applications, quels que soient les droits d'accès octroyés à l'application. Par exemple, même si un fichier was.policy dispose du droit d'accès java.security.AllPermission sur un de ses modules, les droits d'accès spécifiés tels que le droit runtimeFilterMask sont supprimés du droit d'accès octroyé pendant l'exécution.

Edition du fichier de règles

Il est recommandé d'utiliser l'outil policy fourni avec JDK (racine_serveur_app/java/jre/bin/policytool), pour modifier les fichiers de règles précédents. Pour WebSphere Application Server, Network Deployment, extrayez les fichiers de règles du référentiel avant de les modifier. Une fois le fichier extrait, utilisez l'outil policy pour le modifier. Les fichiers de règles modifiés doivent être replacés dans le référentiel et synchronisés avec d'autres noeuds.

Résolution des incidents

Si vous souhaitez déboguer des règles dynamiques, sélectionnez l'une des trois méthodes pour générer un rapport détaillé de l'exception AccessControlException.
  • Trace (Configuré par la trace RAS). Active la trace à l'aide de la spécification de trace :
    Avertissement : La commande suivante tient sur une seule ligne
    com.ibm.ws.security.policy.*=all=enabled:
    com.ibm.ws.security.core.SecurityManager=all=enabled
  • Trace (Configuré par la propriété). Définit une propriété Java java.security.debug. Les valeurs valides pour la propriété java.security.debug sont :
    • Accès. Affiche toutes les informations de débogage, y compris les droits requis, le code, la pile et l'emplacement de la base de code.
    • Pile. Affiche les informations de débogage, y compris le droit requis, le code et la pile.
    • Echec. Affiche les informations de débogage, y compris le droit requis et le code.
  • ffdc. Active ffdc, modifie le fichier ffdcRun.properties en modifiant Level=4 et LAE=true. Recherche un mot clé Access Violation dans le fichier journal.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_rpolicydir
Nom du fichier : rsec_rpolicydir.html