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.

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
Archivo de política | Location |
---|---|
java.policy |
|
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. |
Archivos de política dinámica
Archivo de política | Location |
---|---|
spi.policy | raíz_perfil/config/cells/nombre_célula 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 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 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 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. |
Sintaxis del archivo 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: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 |
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";
};
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. |
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 |
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
- 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.