Seguridad Java 2

La seguridad de Java™ 2 proporciona un mecanismo de control de acceso muy preciso y basado en políticas que aumenta la integridad global del sistema comprobando los permisos antes de ofrecer acceso a determinados recursos protegidos del sistema. La seguridad de Java 2 protege el acceso a los recursos del sistema, como por ejemplo, la E/S de archivos, sockets y propiedades. La seguridad J2EE (Java 2 Platform, Enterprise Edition) protege el acceso a recursos web como por ejemplo, servlets, archivos JSP (JavaServer Pages) y métodos EJB (Enterprise JavaBeans).

Dado que la seguridad de Java 2 es relativamente nueva, es posible que muchas aplicaciones existentes e incluso nuevas no estén preparadas para un modelo de programación de control de acceso tan preciso como el que puede aplicar la seguridad de Java 2. Los administradores deben comprender las consecuencias que probablemente pueda tener el habilitar la seguridad de Java 2 si las aplicaciones no están preparadas para la seguridad de Java 2. La seguridad de Java 2 impone algunos requisitos nuevos en los administradores y desarrolladores de aplicaciones.

[IBM i]Importante: La seguridad de Java 2 se restringe sólo a los programas Java que se ejecutan en una máquina virtual Java que tiene la seguridad de Java 2 habilitada. No protege los recursos del sistema si la seguridad de Java 2 está inhabilitada o si se accede a los recursos del sistema desde otros programas o mandatos. Por lo tanto, si desea proteger los recursos del sistema, deberá utilizar la seguridad del sistema operativo.
Avoid trouble Avoid trouble: El servidor de aplicaciones no soporta una implementación de gestor de seguridad Java personalizado. gotcha

Seguridad de Java 2 para responsables del despliegue y administradores

Aunque la seguridad de Java 2 está soportada, está inhabilitada por omisión. La seguridad de Java 2 y la seguridad administrativa se pueden configurar independientemente una de otra. Si se inhabilita la seguridad administrativa, no se inhabilita la seguridad de Java 2 automáticamente. Deberá inhabilitarla explícitamente.

Si las aplicaciones o las bibliotecas de terceros no están preparadas y se habilita la seguridad de Java 2, se pueden producir problemas. Estos problemas se pueden identificar como excepciones AccessControlExceptions de seguridad de Java 2 en los archivos de registro cronológico del sistema o en los archivos de rastreo. Si no está seguro de que las aplicaciones están preparadas para la seguridad de Java 2, inhabilite la seguridad de Java 2 desde el principio para instalar la aplicación y compruebe que funciona correctamente.

La política que contienen estos archivos de políticas no puede hacerse más restrictiva de lo que ya es debido a que es posible que no se hayan aplicado en el producto las API doPrivileged de Java 2 necesarias. La política restrictiva es la política por omisión. Se pueden otorgar permisos adicionales, pero la política por omisión no se puede hacer más restrictiva, porque las excepciones AccessControlExceptions se generan desde WebSphere Application Server. El producto no da soporte a una política más restrictiva que la política por omisión que se define en los archivos de política mencionados anteriormente.

Para definir la política de seguridad del proceso Java se utilizan varios archivos de política. Estos archivos de políticas son estáticos (codeBase se define en el archivo de política) y se encuentran en el formato de política por omisión proporcionado por IBM® Developer Kit, Java Technology Edition. Para las bibliotecas de programas de utilidad y los recursos de las aplicaciones de empresa, WebSphere Application Server proporciona soporte de política dinámica. La base de código se calcula dinámicamente a partir de la información de despliegue y se otorgan permisos a partir de archivos de política de plantillas durante el tiempo de ejecución. Consulte Archivos de política de seguridad de Java 2. para obtener más información.

Los errores de sintaxis de los archivos de política harán que el proceso del servidor de aplicaciones no se pueda iniciar, por lo tanto edite con cuidado estos archivos de política.

[IBM i]Nota: Edite estos archivos de políticas utilizando la herramienta de políticas proporcionada por IBM Developer Kit, Java Technology Edition. Para obtener más información, consulte el apartado Utilización de PolicyTool para editar archivos de política para la seguridad de Java 2.

Si una aplicación no está preparada para la seguridad de Java 2, si el proveedor de la aplicación no proporciona un archivo was.policy como parte de la aplicación, o si el proveedor de la aplicación no comunica los permisos esperados, es muy probable que la aplicación genere excepciones de control de acceso de seguridad de Java 2 en el tiempo de ejecución. Es posible que no resulte obvio que una aplicación no esté preparada para la seguridad de Java 2. Existen varias ayudas de depuración en tiempo de ejecución que ayudan a solucionar los problemas en las aplicaciones con excepciones de control de acceso. Consulte las ayudas de depuración de la seguridad de Java 2 para obtener más detalles. Consulte Manejo de aplicaciones que no están preparadas para la seguridad de Java 2 para obtener más información y estrategias para tratar con esas aplicaciones.

Es importante tener en cuenta que, cuando la seguridad de Java está habilitada en los valores de seguridad administrativa, el gestor de seguridad instalado no comprueba actualmente los permisos modifyThread y modifyThreadGroup de las hebras que no son del sistema. Si se crea o se modifica una hebra con el código de aplicación EJB (Enterprise JavaBeans) y Web, puede afectar negativamente a otros componentes del contenedor y a la capacidad del contenedor para gestionar transacciones y ciclos de vida de enterprise bean.

Seguridad de Java 2 para los desarrolladores de aplicaciones

Los desarrolladores de aplicaciones deben comprender los permisos que se otorgan en la política por omisión de WebSphere y los requisitos de los permisos de las API SDK a los que llama la aplicación para saber si se necesitan permisos adicionales. La referencia Permisos de Java 2 SDK del apartado de recursos describe los permisos que requiere cada API.

Los proveedores de aplicaciones pueden presuponer que las aplicaciones tienen los permisos que se otorgan en la política por omisión mencionada anteriormente. Las aplicaciones que acceden a los recursos que no están cubiertos por la política por omisión de WebSphere deben otorgar los permisos de seguridad de Java 2 adicionales a la aplicación.

Aunque es posible otorgar permisos adicionales a la aplicación en uno de los demás archivos de políticas dinámicas s de WebSphere o en uno de los archivos de políticas estáticas java.policy más tradicionales, el archivo was.policy, que está incluido en el archivo EAR, garantiza que los permisos adicionales estén dentro del ámbito de la aplicación exacta que los necesita. Si el ámbito del permiso va más allá del código de aplicación que lo necesita, puede permitir código que normalmente no tiene permiso pueda acceder a determinados recursos.

Si se está desarrollando un componente de aplicación como, por ejemplo, una biblioteca que realmente se puede incluir en más de un archivo .ear, entonces el desarrollador de la biblioteca debe documentar los permisos Java 2 que necesita el ensamblador de aplicaciones. No hay ningún archivo was.policy para los componentes library-type. El desarrollador debe comunicar los permisos necesarios mediante la documentación de la interfaz de programación de aplicaciones (API) o algún otro documento externo.

Si la biblioteca de componentes la comparten varias aplicaciones de la empresa, se pueden otorgar los permisos a todas las aplicaciones del nodo en el archivo app.policy.
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.

Si el permiso solamente lo utiliza internamente la biblioteca de componentes y nunca se otorga a la aplicación el acceso a los recursos que protege el permiso, es posible que sea necesario marcar el código como privilegiado. Consulte el tema AccessControlException para obtener más información. No obstante, si se inserta incorrectamente una llamada doPrivileged podrían abrirse brechas de seguridad. Es necesario comprender las implicaciones de la llamada doPrivileged para tomar la decisión correcta.

La sección sobre archivos de políticas dinámicos de Archivos de política de seguridad de Java 2. describe cómo se conceden los permisos en los archivos was.policy durante la ejecución.

Es posible que para desarrollar una aplicación para utilizarla con la seguridad de Java 2 se necesiten nuevos conocimientos y requiera que los desarrolladores de aplicaciones tengan en cuenta la seguridad de un modo que anteriormente no era necesario. Describir el modelo de seguridad de Java 2 y lo que implica para el desarrollo de aplicaciones va más allá del ámbito de esta sección. El siguiente URL le ayudará a comenzar: http://java.sun.com/j2se/1.5.0/docs/guide/security/index.html.

Ayudas para depuración

El archivo SYSOUT de WebSphere Application Server y la propiedad com.ibm.websphere.java2secman.norethrow son las dos ayudas principales en la depuración.

Los archivos de registro del sistema o los archivos de rastreo de WebSphere

La excepción AccessControl anotada cronológicamente en los archivos de registro cronológico del sistema o los archivos de rastreo contiene la violación de permisos que genera la excepción, la pila de llamadas a la excepción y los permisos concedidos a cada trama de la pila. Generalmente, esta información basta para determinar el permiso que falta y el código que requiere el permiso.

La propiedad com.ibm.websphere.java2secman.norethrow

Cuando está habilitada la seguridad de Java 2 en WebSphere Application Server, el componente de gestor de seguridad crea una excepción java.security.AccessControl cuando se produce una violación de los permisos. Esta excepción, si no se maneja, a menudo produce un error de tiempo ejecución. Esta excepción también se anota cronológicamente en el archivo SYSOUT.

No obstante, cuando se establece la propiedad com.ibm.websphere.java2secman.norethrow de Java Virtual Machine y su valor es true, el gestor de seguridad no crea la excepción AccessControl. Esta información se anota cronológicamente.

Esta propiedad está diseñada para un entorno de depuración porque indica al gestor de seguridad que no ha de crear la excepción AccessControl. La seguridad de Java 2 no se fuerza. No utilice esta propiedad en un entorno de producción en el que una entorno de seguridad de Java 2 relajada debilite la integridad que debe crear la seguridad de Java 2.

Esta propiedad es útil en un entorno de depuración o de prueba en el que la aplicación se puede comprobar detenidamente y se pueden examinar los archivos de registro del sistema o los archivos de rastreo para ver si hay excepciones AccessControl. Como esta propiedad no crea la excepción AccessControl, no propaga la pila de llamadas y no produce un error. Sin esta propiedad, debe encontrar y solucionar las excepciones AccessControl una a una.

Manejo de aplicaciones que no están preparadas para la seguridad de Java 2

Si la integridad del sistema adicional que proporciona Java 2 es importante, póngase en contacto con el proveedor de las aplicaciones para que éstas den soporte a la seguridad de Java 2 o que especifique como mínimo los permisos adicionales que se deben otorgar aparte de la política de WebSphere Application Server por omisión.

El modo más fácil de manejar este tipo de aplicaciones es inhabilitar la seguridad de Java 2 en WebSphere Application Server. El inconveniente es que esta solución se aplica a todo el sistema y que la integridad del sistema no es tan fuerte como podría ser. Puede que no sea conveniente inhabilitar la seguridad de Java 2, dependiendo de las políticas de seguridad de organización o la tolerancia a errores.

Otro enfoque es dejar habilitada la seguridad de Java 2, y otorgarle sólo los permisos adicionales necesarios o todos los permisos sólo a la aplicación que esté dando problemas. No obstante, otorgar permisos puede que no resulte una tarea fácil de realizar. Si el proveedor de la aplicación no le ha especificado de algún modo los permisos necesarios, no existe un modo fácil de determinar cuáles son los permisos necesarios y la única opción posible será otorgar todos los permisos. Este riesgo se minimiza si se coloca esta aplicación en un nodo diferente, con lo cual se puede aislar de determinados recursos. Otorgue el permiso java.security.AllPermission en el archivo was.policy que hay incorporado en el archivo .ear de la aplicación, por ejemplo:
grant codeBase "file:${application}" {
            permission java.security.AllPermission;
        };

El archivo server.policy

[AIX Solaris HP-UX Linux Windows][z/OS]El archivo server.policy se encuentra en el directorio raíz_servidor_aplicaciones/properties/.

[IBM i]El archivo server.policy se encuentra en el directorio raíz_perfil/properties.

Esta política define la política para las clases de WebSphere Application Server. Actualmente, todos los procesos del servidor de la misma instalación comparten el mismo archivo server.policy. No obstante, puede configurar este archivo para que cada proceso de servidor pueda tener un archivo server.policy aparte. Defina el archivo de política como el valor de las propiedades del sistema Java java.security.policy. Si desea obtener más información sobre cómo definir las propiedades del sistema Java, consulte la sección Definición de proceso del archivo Gestionar servidores de aplicaciones.

El archivo server.policy no es un archivo de configuración gestionado por el repositorio y el servicio de réplica de archivos. Los cambios realizados en este archivo son locales y no se replican en otras máquinas. Utilice el archivo server.policy para definir la política de seguridad de Java 2 de los recursos de servidor. Utilice el archivo app.policy (por nodo) o el archivo was.policy (por aplicación de empresa) para definir la política de seguridad de Java 2 para recursos de aplicación de empresa.
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.

El archivo java.policy

El archivo representa los permisos por omisión que se conceden a todas las clases. La política de este archivo se aplica a todos los procesos iniciados por la Java Virtual Machine de WebSphere Application Server.

[AIX Solaris HP-UX Linux Windows][z/OS]El archivo java.policy se encuentra en el directorio raíz_servidor_aplicaciones/java/lib/security.

[IBM i]El archivo java.policy se encuentra en el directorio ${java.home}/lib/security/ donde ${java.home} es la vía de acceso al SDK (Software Development Kit) que se está utilizando. El archivo de políticas se utiliza en todo el sistema operativo. No edite el archivo java.policy.

Resolución de problemas

Mensaje de error CWSCJ0314E

Síntoma:

Mensaje de error CWSCJ0314E: Actual la política de seguridad de Java 2 actual ha informado acerca de una violación potencial de los permisos de seguridad de Java 2. Consulte la guía de determinación de problemas si desea más información. {0}Permission\:{1}Code\:{2}{3}Stack Trace\:{4}Code Base Location\:{5} Actual La política de seguridad de Java 2 ha informado acerca de una violación potencial de los permisos de seguridad de Java 2. Consulte la guía de determinación de problemas para obtener más información. {0}Permiso\:{1}Código\:{2}{3}Rastreo de pila\:{4}Ubicación del código base\:{5}

Problema:

El método checkPermission del gestor de seguridad de Java ha informado acerca de una excepción de seguridad en el permiso de sujeto con información de depuración. La información indicada puede ser diferente dependiendo de la configuración del sistema. Este informe se habilita configurando el rastreo RAS ((Reliability Availability and Serviceability) en modalidad de depuración o especificando una propiedad Java.

Consulte Cómo habilitar el rastreo para obtener más información sobre cómo configurar el rastreo RAS en la modalidad de depuración.

Especifique la propiedad siguiente en el panel Valores de JVM desde la consola administrativa: java.security.debug. Los valores válidos incluyen:
access
Imprimir toda la información de depuración: el permiso necesario, el código, la pila y la ubicación del código base.
pila
Imprimir la información de depuración: el permiso necesario, el código y la pila.
failure
Imprimir la información de depuración: el permiso necesario y el código.

Respuesta recomendada:

La excepción generada puede ser muy grave para el sistema seguro. Active el rastreo de seguridad para determinar el código potencial que puede haber violado la política de seguridad. Cuando se haya determinado de qué código se trata, compruebe si la operación que ha intentado está permitida con respecto a la seguridad de Java 2, analizando todos los archivos de políticas de seguridad de Java 2 aplicables y el código de la aplicación.

Si la aplicación se está ejecutando con Java Mail, es posible que este mensaje no sea tan grave. Puede actualizar el archivo was.policy para conceder los permisos siguientes a la aplicación:

permission java.io.FilePermission  "${user.home}${/}.mailcap", "read";
permission java.io.FilePermission "${user.home}${/}.mime.types", "read";
permission java.io.FilePermission "${java.home}${/}lib${/}mailcap",  "read";
permission java.io.FilePermission "${java.home}${/}lib${/}mime.types",  "read";

SecurityException - Acceso denegado

Síntoma:

Si se ha habilitado la seguridad de Java, y los permisos para leer el archivo jaxm.properties no se han concedido, cuando se crea una instancia de SOAPFactory a través de una llamada a javax.xml.soap.SOAPFactory.newInstance(), o se crea una instancia de MessageFactory mediante una llamada a MessageFactory.newInstance(), se produce una excepción SecurityException y se escribe la siguiente excepción en el registro del sistema:
Permiso:

      /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties : access denied
(java.io.FilePermission /opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties
read)

Código:

     com.ibm.ws.wsfvt.test.binding.addr1.binder.AddressBinder
in  {file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/
ahp6405Node01Cell/DataBinding.ear/address1.war/WEB-INF/lib
/addressbinder1.jar}

Rastreo de pila:

java.security.AccessControlException: access denied (java.io.FilePermission
/opt/IBM/WebSphere/AppServer/java/jre/lib/jaxm.properties read)
.

Problema:

La política de seguridad de Java 2 informa de una violación potencial del permiso de seguridad de Java 2

Respuesta recomendada:

SOAPFactory ignora la excepción y continúa con el siguiente medio de determinar la implementación que se ha de cargar. Por lo tanto, puede ignorar la entrada de registro para esta excepción de seguridad.

Puesto que este producto utiliza SOAPFactory para dar soporte a otras tecnologías de servicios web, como WS-Addressing (WS-A), WS-Atomic Transaction (WS-AT) y WS-Notification, puede ignorar esta SecurityException en cualquier aplicación de servicios web donde se haya habilitado la seguridad Java.

Mensajes

Message: CWSCJ0313E: Los distintivos de mensajes de depuración del gestor de seguridad de Java 2 se han inicializado\: TrDebug: {0}, Access: {1}, Stack: {2}, Failure: {3}

Problema: Los valores configurados de los distintivos válidos de los mensajes de depuración del gestor de seguridad.

Mensaje: CWSCJ0307E: Se ha captado una excepción imprevista al intentar determinar la ubicación del código base. Excepción: {0}

Problema: Se ha captado una excepción imprevista al determinar la ubicación del código base.


Icon that indicates the type of topic Concept topic



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