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.

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
Fichier de règles | Emplacement |
---|---|
java.policy |
|
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. |
fichiers de règles dynamiques
Fichier de règles | Emplacement |
---|---|
spi.policy | racine_profil/config/cells/nom_cellule 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 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 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 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. |
Syntaxe du fichier de règles
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 :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. |
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";
};
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. |
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 |
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
- 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.