Archivos de política de seguridad de Java 2.

Las especificaciones J2EE (Java™ 2 Platform, Enterprise Edition) 1.3 y posteriores tienen un modelo de programación bien definido de responsabilidades entre los proveedores de contenedores y el código de aplicación. Se recomienda utilizar el gestor de seguridad de Java 2 para ayudar a forzar este modelo de programación. Algunas operaciones no están permitidas en el código de aplicación, ya que interfieren con el funcionamiento de los contenedores. El gestor de seguridad de Java 2 se utiliza en el producto para forzar las responsabilidades del contenedor y el código de aplicación.

Avoid trouble Avoid trouble: El servidor de aplicaciones no soporta una implementación de gestor de seguridad Java personalizado. gotcha

Este producto da soporte a la gestión de los archivos de política. Varios archivos de política del producto son estáticos o dinámicos. La política dinámica es una plantilla de permisos para un tipo concreto de recurso. No hay definida ninguna base de código relativa en la plantilla de política dinámica. La base de código se calcula dinámicamente a partir del despliegue y los datos de tiempo de ejecución.

Archivos de política estática

Tabla 1. Archivos de política estática.

En esta tabla se muestra la ubicación de los archivos de política estática.

Archivo de política Location
java.policy

[AIX Solaris HP-UX Linux Windows][z/OS]raíz_servidor_aplic/java/jre/lib/security/java.policy. Se otorgan permisos por omisión a todas las clases. La política de este archivo se aplica a todos los procesos ejecutados por WebSphere Application Server.

server.policy raíz_perfil/properties/server.policy. Se otorgan permisos por omisión a todos los servidores del producto.
client.policy raíz_perfil/properties/client.policy. Se otorgan permisos por omisión para todos los applets y contenedores del cliente del producto en un nodo.
Los archivos de políticas estáticas no están gestionados por la configuración y los servicios de réplica de archivos. Los cambios realizados en estos archivos son locales y no se duplican en otros nodos de la célula de WebSphere Application Server, Network Deployment.

Archivos de política dinámica

Tabla 2. Archivos de política dinámica.

En esta tabla se muestra la ubicación de los archivos de política dinámica.

Archivo de política Location
spi.policy

raíz_perfil/config/cells/nombre_célula
/nodes/nombre_nodo/spi.policy

Esta plantilla es para la Interfaz de proveedor de servicio (SPI) o los recursos de terceros incorporados en el producto. Ejemplos de SPI son JMS (Java Message Service) en MQ Series y los controladores JDBC (Java Database Connectivity). La base de código de los recursos incorporados se determina dinámicamente a partir la configuración (archivo resources.xml) y los datos de tiempo de ejecución, y los permisos definidos en los archivos spi.policy se aplican automáticamente a estos recursos y archivos JAR especificados en la classpath de un adaptador de recursos. El permiso por omisión del archivo spi.policy es java.security.AllPermissions.

library.policy

raíz_perfil/config/cells/nombre_célula/nodes
/nombre_nodo/library.policy

Esta plantilla es la de la biblioteca (clases de biblioteca de Java). Puede definir una biblioteca compartida, para utilizarla en varias aplicaciones del producto. El permiso por omisión del archivo library.policy es empty.

app.policy

raíz_perfil/config/cells/nombre_célula
/nodes/nombre_nodo/app.policy

El archivo app.policy define los permisos por omisión otorgados a todas las aplicaciones de empresa que se ejecutan en nombre_nodo en nombre_célula.
Nota: Las actualizaciones del archivo app.policy sólo se aplican a las aplicaciones empresariales que están en el nodo al que pertenece el archivo app.policy.
was.policy

raíz_perfil/config/cells/nombre_célula
/applications/nombre_archivo_ear/deployments/
nombre_aplicación/META-INF/was.policy

Esta plantilla es la de los permisos específicos de la aplicación. El archivo was.policy está incorporado en el archivo EAR (Enterprise Archive).

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

Este archivo puede tener una especificación de permiso definida en el archivo ra.xml. El archivo ra.xml está incorporado en el archivo RAR.

Las entradas grant especificadas en los archivos app.policy y was.policy deben tener una base de código definida. Si las entradas grant se especifican sin una base de código, los archivos de política no se cargan correctamente y la aplicación puede fallar. Si el objetivo es otorgar los permisos a todas las aplicaciones, utilice file:${application} como base de código en la entrada grant.

Sintaxis del archivo de política

Un archivo de política contiene varias entradas de política. En el siguiente ejemplo se muestra cada uno de los formatos de entrada de política:
grant [codebase <Codebase>] {
permission <Permission>;
 permission <Permission>;
permission <Permission>;
};

<CodeBase>: 	A URL.
						Por ejemplo, "file:${java.home}/lib/tools.jar"
												Cuando no se especifica [codebase <Codebase>], los permisos de la lista 
               se aplican a todo.
												Si el URL finaliza con un nombre de archivo JAR, sólo las clases del archivo JAR 
               pertenecerán al codebase.
               Si el URL finaliza con "/", sólo los archivos de clases del directorio
               especificado pertenecerán al codebase.
               Si el URL finaliza con "*", todos los archivos de clases y JAR del directorio
               especificado pertenecerán al codebase.
               Si el URL finaliza con "-", todos los archivos de clases y JAR del directorio especificado y 
               los subdirectorios pertenecerán al codebase.
<Permissions>: Se compone de
														Tipo de permiso      	: nombre de clase del permiso
     										Nombre de destino 	: nombre que especifica el destino
     										Acciones          	: acciones permitidas en el destino
			Por ejemplo:        						java.io.FilePermission "/tmp/xxx", "read,write"
Consulte las especificaciones del kit de desarrollador para obtener más información sobre cada permiso.

Sintaxis de la política dinámica

Puede definir permisos para tipos específicos de recursos en los archivos de política dinámica de una aplicación de empresa. Para ello, se utilizan los símbolos reservados del producto. El ámbito de símbolos reservado depende de dónde se defina. Si se definen los permisos en el archivo app.policy, la señal se aplica a todos los recursos en todas las aplicaciones de empresa que se ejecutan en nombre_nodo. Si se definen los permisos en el archivo META-INF/was.policy, la señal sólo se aplica a la aplicación de empresa específica. En la siguiente tabla se incluyen los símbolos válidos para la base de código:
Tabla 3. Sintaxis de política dinámica.

En esta tabla se describen los símbolos válidos de la base de código de los archivos de política dinámica.

Símbolo Significado
file:${application} Los permisos se aplican a todos los recursos de la aplicación
file:${jars} Los permisos se aplican a todos los archivos JAR (Java Archive) de programa de utilidad de la aplicación.
file:${ejbComponent} Los permisos se aplican a los recursos EJB (Enterprise JavaBeans) de la aplicación
file:${webComponent} Los permisos se aplican a los recursos web de la aplicación
file:${connectorComponent} Los permisos se aplican a los recursos de conector de la aplicación
Puede especificar el nombre de módulo de un valor granular, excepto en aquellas entradas especificadas por los símbolos de la base de códigos. Por ejemplo:
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";
};
Las líneas sexta y séptima del ejemplo de código anterior son una línea continua. Sólo puede utilizar una base de código relativa en el archivo META-INF/was.policy. Se definen varios símbolos reservados del producto para asociar las listas de permisos a un tipo específico de recursos.
Tabla 4. Sintaxis de política dinámica.

En esta tabla se describen varios símbolos reservados del producto que se definen para asociar las listas de permisos a un tipo específico de recurso.

Símbolo Significado
file:${application} Los permisos se aplican a todos los recursos de la aplicación
file:${jars} Los permisos se aplican a todos los archivos JAR de programa de utilidad de la aplicación
file:${ejbComponent} Los permisos se aplican a los recursos de enterprise beans de la aplicación
file:${webComponent} Los permisos se aplican a los recursos web de la aplicación
file:${connectorComponent} Los permisos se aplican a los recursos de conector, tanto a los de la aplicación como a los recursos de conectores autónomos.
Se proporcionan cinco símbolos para especificar la vía de acceso y el nombre del permiso java.io.FilePermission. Estos símbolos permiten la especificación flexible de permisos. La vía de acceso absoluta del archivo se fija después de la instalación de la aplicación.
Tabla 5. Sintaxis de política dinámica.

En esta tabla se describen los símbolos incorporados que se proporcionan para especificar la vía de acceso y el nombre del permiso java.io.FilePermission.

Símbolo Significado
${app.installed.path} Vía de acceso donde se instala la aplicación
${was.module.path} Vía de acceso donde se instala el módulo
${current.cell.name} Nombre de célula actual
${current.node.name} Nombre de nodo actual
${current.server.name} Nombre de servidor actual
Atención: No utilice ${was.module.path} en la entrada ${application}.

Determine con cuidado dónde va a añadir un nuevo permiso. Un permiso especificado incorrectamente genera una excepción AccessControlException. Como la política dinámica resuelve el código base durante la ejecución, no es fácil determinar qué archivo de política presenta un problema. Añada un permiso sólo a los recursos necesarios. Por ejemplo, utilice ${ejbcomponent}, y etc en lugar de ${application}, y actualice el archivo was.policy en lugar del archivo app.policy, si es posible.

Filtros de política estática

Existe un soporte de filtros de políticas estáticas limitado. Si el archivo app.policy y el archivo was.policy tienen permisos definidos en el archivo filter.policy con la palabra clave filterMask, el tiempo de ejecución elimina los permisos de las aplicaciones y se registra un mensaje de auditoría. Sin embargo, si los permisos definidos en los archivos app.policy y was.policy son permisos compuestos, por ejemplo, java.security.AllPermission, el permiso no se suprime, si no que se escribe un mensaje de aviso en el archivo de registro cronológico. El filtro de política sólo da soporte a permisos de Developer Kit; el nombre del paquete de permisos empezará por java o javax.

Se da soporte de filtro de políticas de tiempo de ejecución para forzar un filtrado más estricto. Si el archivo app.policy y el archivo was.policy tienen permisos definidos en el archivo filter.policy con la palabra clave runtimeFilterMask, el tiempo de ejecución elimina los permisos de las aplicaciones, independientemente de qué permisos se otorguen a la aplicación. Por ejemplo, aunque el archivo was.policy tenga el permiso java.security.AllPermission otorgado a uno de sus módulos, los permisos especificados como el permiso runtimeFilterMask se eliminan del permiso otorgado durante la ejecución.

Edición de archivos de política

Se recomienda utilizar la herramienta de políticas que se proporciona en el Developer Kit (raíz_servidor_aplic/java/jre/bin/policytool), para editar los archivos de política anteriores. En WebSphere Application Server, Network Deployment, extraiga los archivos de política del depósito antes de editarlos. Una vez extraído el archivo de política, se puede utilizar la herramienta de políticas para editar el archivo. Compruebe los archivos de política modificados en el repositorio y sincronícelos con otros nodos.

Resolución de problemas

Para depurar la política dinámica, hay tres formas de generar el informe detallado de la excepción AccessControlException.
  • Rastreo (Configurado por el rastreo de RAS). Habilita los rastreos con la especificación de rastreo:
    Atención: El siguiente mandato es una línea continua
    com.ibm.ws.security.policy.*=all=enabled:
    com.ibm.ws.security.core.SecurityManager=all=enabled
  • Rastreo (Configurado por la propiedad). Especifica una propiedad java.security.debug de Java. Los valores válidos de la propiedad java.security.debug son los siguientes:
    • Acceso. Imprimir toda la información de depuración, incluidos el permiso necesario, el código, la pila y la ubicación del código base.
    • Pila. Imprima la información de depuración, incluidos el permiso necesario, el código y la pila.
    • Anomalía. Imprima la información de depuración, incluidos el permiso necesario y el código.
  • ffdc. Habilite ffdc, modifique el archivo ffdcRun.properties cambiando Level=4 y LAE=true. Busque la palabra clave Violación de acceso en el archivo de registro cronológico.

Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_rpolicydir
File name: rsec_rpolicydir.html