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

fichiers de règles statiques

fichiers de règles dynamiques

Syntaxe du fichier de règles

grant [codebase <Codebase>] {
permission <Permission>;
 permission <Permission>;
permission <Permission>;
};

<CodeBase>: 	A URL.
			For example,  "file:${java.home}/lib/tools.jar"
						When [codebase <Codebase>] is not specified, listed 
               permissions are applied to everything.
						If URL ends with a JAR file name,  only the classes in the 
               JAR file belong to the codebase.
               If URL ends with "/", only the class files in the specified
               directory belong to the codebase.
               If URL ends with "*", all JAR and class files in the specified
               directory belong to the codebase.
               If URL ends with "-", all JAR and class files in the specified 
               directory and its subdirectories belong to the codebase.
<Permissions>: Consists from
							Permission Type  	: class name of the permission
     					Target Name      	: name specifying the target
     					Actions          	: actions allowed on target
			For example,
      			java.io.FilePermission "/tmp/xxx", "read,write"

Syntaxe de règles dynamique

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";
};

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 :use ${ejbcomponent}etetcau lieu de${application}et mettez à jour lewas.policyà la place du fichierapp.policysi possible.

Filtrage de la règle statique

Un filtrage restreint de la règle statique est possible. Si l'élément XMLapp.policyet le fichierwas.policyont des droits d'accès définis dans le fichierfilter.policyavec le mot clé thefilterMask , l'environnement d'exécution supprime les droits des applications et un message d'audit est consigné. Toutefois, si les droits définis dans leapp.policyet duwas.policyLes fichiers sont des droits composés, par exemple, java.security.AllPermission, l'autorisation n'est pas supprimée, mais un message d'avertissement est consigné dans le fichier journal. Le filtrage des règles ne prend en charge que les droits du kit de développement ; le nom du package de droits commence parjavaoujavax.

Le filtrage des stratégies de l'environnement d'exécution est pris en charge pour renforcer le filtrage. Si l'élément XMLapp.policyet le fichierwas.policyont des droits d'accès définis dans le fichierfilter.policyavec le mot clé runtimeFilterMask, l'environnement d'exécution supprime les droits des applications, quels que soient les droits accordés à l'application. Par exemple, même si unwas.policycontient le fichier java.security.AllPermission accordée à l'un de ses modules, les autorisations spécifiées, telles que l'autorisation runtimeFilterMask, sont supprimées de l'autorisation accordée lors de l'exécution.

Edition du fichier de règles

A l'aide de l'outil de règles fourni par Developer Kit (app_server_root/java/jre/bin/policytool), pour éditer les fichiers de règles précédents est recommandé. Pour WebSphere Application Server Network Deployment, extrayez les fichiers de règles du référentiel avant de les éditer. 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.

Traitement des incidents